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

Откуда: Москва/Протвино
Сообщений: 4274
Привет. Я хоть и не Маркеленков, но встрять считаю необходимым. Для начала, хотелось бы, собственно, вернуться в начало :-). А именно - к обсуждение лично я подключился с целью поддержать вот это:
Известный Серый Ник
3) select myseq.nextval from dual советовать без оговорок (в том числе, что это не единственный и не лучший метод)
И указал на сомнительность подхода, при котором от первичного/уникального ключа требуется что-то большее (а именно - упорядоченность), нежели голимая уникальность.
Ааз
Только не говорите, что логика работы вашего приложения предполагает, что номера, извлеченные из последовательности, монотонно нарастают.
Далее, скорее для подчеркивания возникновения излишних технических сложностей, привел пример конкуренции за листовые блоки индекса при одновременной вставке.

Вот это и был контекст, заданный для обсуждения. Разве нет?

Далее Grami привел использование global partition by hash для решения этих излишних сложностей. Само упоминание технической возможности решения заслуживает одобрения. Факт. Если уж вы таки попали, то не все еще пропало :-). Правда, на мой вкус, бравурненько прозвучало. Но да бог с ним. Не помню кто сказал, что (не цитата, но близко по смыслу) "наиболее элегантные технические решения зачастую рождаются при устранении проколов проектирования".

А вот сравнение global partition by hash с реверсивным индексом мне, как раз, показалось подменой (уверен, что несознательной) контекста. С чего и появилась пена... блин... как дети малые...

Ну и, собственно, "к телу":
Владимир Бегун
Что в предложенном варианте решения является весомым недостатком, по сравнению с обсуждаемой альтернативой? Опять же не нужно выходить из контекста обсуждаемой проблемы.
1. Продвигаемое решение возможно только в EE+Partitioning. Я тут взял калькулятор, который быстренько мне прикинул разницу для упомянутых тобой, Володя, 50 пользователей. Насчитал минимум ~$50,000 разницы. При том, что для EE+Partitioning пришлось оставить только 2 проца vs 4 (лицензирование по Named User). Остальные варианты как-то похуже смотрелись. Или ты скажешь, что это не технический аргумент? Не знаю, не знаю... В этом бизнесе... для некоторых людей названная цифра - полугодовой оклад, а для некоторых контор - (полу-)годовой бюджет на IT :-). Ну это я так... недавней дискуссией на oracle-l@freelists.org навеяло.
2. Для тех клиентов, которым без Partitioning сложно, решение тоже не фонтан. Ибо с большой вероятностью для начала будет секционирована сама таблица. Можно даже с 90% уверенностью говорить про RANGE :-). Глобальный индекс, необходимость не только добавлять, но и drop/exchange/move partition весьма высока. Про техническую возможность "update global indexes" я знаю ;-).
3. Альтернатива, конечно, сомнительного качества. Но давай чуток добавим общности, ок? Кто такой этот REVERSE, если опустить мелкие детали? FBI по функции reverse. Согласен? Что мешает написать свой более разумный рандомизатор, гарантирующий уникальность, но, в отличие от reverse, использующий кучную стрельбу по группе листовых блоков вместо одного крайнего? Правда FBI - часть Data Warehousing. Но в приложении-то можно укодировать аналог? Бери свой sequence, читай из него уникальное число, правильно рандомизируй - и вуаля. Причем для этого проектировщику достаточно знать о возможной конкуренции (читай "снижении масштабируемости") и необязательности вызвавшего ее подхода к организации данных. Ну и еще немного напрячь моск :-).

Всего
PS. Народу не нужны "волшебных палочек" и "серебрянных пуль". ГЫыыы
--
Disclaimer: Opinions are of my own and not necessar(-il)y ...
7 янв 07, 19:09    [3612210]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Магъ
Guest
Экзема Острицевна
НЕприятно читать

Чукча не читатель, чукча - писатель?

Ааз
И указал на сомнительность подхода, при котором от первичного/уникального ключа требуется что-то большее (а именно - упорядоченность), нежели голимая уникальность.
Ааз
Только не говорите, что логика работы вашего приложения предполагает, что номера, извлеченные из последовательности, монотонно нарастают.
Далее, скорее для подчеркивания возникновения излишних технических сложностей, привел пример конкуренции за листовые блоки индекса при одновременной вставке.

Вот это и был контекст, заданный для обсуждения. Разве нет?



Парадоксальный мир: в Виларибе на системах с честно купленным оракл (не ЕЕ) за большие бабосы происходят траблы с конкуренцией за блоки индекса по сиквенсу. А в Вилабаджо где юзают пиратку - продолжают веселиться с hash partitions.
7 янв 07, 23:50    [3612476]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
А.Криушин
Далее, скорее для подчеркивания возникновения излишних технических сложностей, привел пример конкуренции за листовые блоки индекса при одновременной вставке.
Да, всё верно.
А.Криушин
Вот это и был контекст, заданный для обсуждения. Разве нет?
Отчасти. Далее была реплика о том, что данную конкуренцию можно в той или иной мере устранить, можно использовать один и/или другой способ. И высказанно мнение по-поводу этих способов. В этом не было ничего технически неверного. Я говорил о контексте, в котором подход упомянутый Grami был обхаян без всяких разумных тех. доводов. Кроме того, там (в реплике от Grami) не было высказано противопоставлений сказанному тобой -- лишь комплемент. В ответ -- более чем странная реплика от твоего коллеги.
А.Криушин
Далее Grami привел использование global partition by hash...
Неверно! Было сказано о "hash partitioned index". Это я сделал пример на основе global индекса, для того чтобы проиллюстрировать проблему. Я мог бы сделать это применив более сложные примеры, но зачем? Ведь оппонент "знает" :-) о проблеме.
А.Криушин
... для решения этих излишних сложностей. Само упоминание технической возможности решения заслуживает одобрения. Факт.
Т.е. человек в рамках дискуссии высказал достаточно здравую мысль, если есть конкуренция описаная тобою выше, одним из возможных её решений может быть предложенное. Далее он высказал своё собственное мнение, базированное на опыте и практике (человек проектирует биллинговые системы). С Grami я не знаком, поэтому ничего ни за ни против не могу. Но технически довод был верен.
А.Криушин
Если уж вы таки попали, то не все еще пропало :-). Правда, на мой вкус, бравурненько прозвучало.
Это, по твоим же словам, (смею предположить) прозвучало несколько лучше чем "НЕприятно читать посты человека, СЛАБО разбирающегося в предмете." На что я и указал. Можно было бы аргрументированно поспорить с доводом относительно смерти reverse indexes, если этого тах хотелось.
А.Криушин
А вот сравнение global partition by hash с реверсивным индексом мне, как раз, показалось подменой (уверен, что несознательной) контекста.
Почему? Ты сказал о конкуренции, последовала реплика о том как её можно устранить и был предложен способ, который достаточно неплохо работает.
А.Криушин
Владимир Бегун
Что в предложенном варианте решения является весомым недостатком, по сравнению с обсуждаемой альтернативой? Опять же не нужно выходить из контекста обсуждаемой проблемы.
1. Продвигаемое решение возможно только в EE+Partitioning.
Нет, не "продвигаемое решение", а альтернатива [я бы сказал "перпендикулярная" :-) альтернатива] reversed индексу, применяемое тогда когда его разумно и можно применять. (в рамках редакции и проч., это, на мой взгляд, достаточно очевидно). Говорить банальности "Оба подхода имеют ряд достоинств и недостатков" -- это наивно, когда просто нужно сравнить два момента на которые было указано (возможности сравнений и уменьшени i/o).
А.Криушин
Я тут взял калькулятор, который быстренько мне прикинул разницу для упомянутых тобой, Володя, 50 пользователей. Насчитал минимум ~$50,000 разницы. При том, что для EE+Partitioning пришлось оставить только 2 проца vs 4 (лицензирование по Named User). Остальные варианты как-то похуже смотрелись. Или ты скажешь, что это не технический аргумент? Не знаю, не знаю... В этом бизнесе... для некоторых людей названная цифра - полугодовой оклад, а для некоторых контор - (полу-)годовой бюджет на IT :-). Ну это я так... недавней дискуссией на oracle-l@freelists.org навеяло.
Ну, начнём с того что я не говорил о 50 пользователях. Я сказал лиши о том что в случае наличия реальной конкуренции результат будет ещё хуже. Оно может и 2 и 3 одновременно работающих сессиях/сеансах умирать... я показал на 1; я бы мог сказать 10,20,100 -- разницы нет -- всё будет тем хуже чем больше желающих использовать этот индекс для вставок. Далее, твоё желание технический аспект заменить финансовым в данном случае не работает... не можете использовать -- не используйте. Как я уже сказал тут не в количестве одновременно работающих сеансов проблема, их количество является лишь ухудшающим фактором. В общем случае, ты проигрыш будешь получать каждую следущую секунду от простого использования (insert) обсуждаемого (reverse) индекса даже на системе с 1 пользователем -- я привёл пример.
А.Криушин
2. Для тех клиентов, которым без Partitioning сложно, решение тоже не фонтан. Ибо с большой вероятностью для начала будет секционирована сама таблица.
Это не довод в данном контексте, а твоя выдумка. Даже если это и будет сделано, то перед тем как делать это доводом сделай тоже самое в случае reverse индекса. Тот пример, который я привёл лишь иллюстрация подхода и проблемы reverse индекса. Т.е. ты партиционируй таблицу, как считаешь нужным, а потом сравни производительность решений. Пока я этого не увидел.
А.Криушин
Можно даже с 90% уверенностью говорить про RANGE :-). Глобальный индекс, необходимость не только добавлять, но и drop/exchange/move partition весьма высока. Про техническую возможность "update global indexes" я знаю ;-).
Ты другой аспект обсуждаешь. См. выше. Первое что ты должен сделать это показать что в том случае, когда ты приводишь диапазонное секционирование как аргумент против хэш-секционирования [а оно, если не очевидно, может быть разным :-), в зависимости от области применения] ты должен показать что использование reverse индекса будем более приемлемым. Кроме того я рекомендую оглянутся и уточнить для чего в системе чаще всего используются последовательности и для обеспечения чего используются ограничения (constraints).

Далее, из общих соображений, без наличия деталей о системе, задаче, режимах эксплуатации -- все что ты сказал может или не может быть реальностью, а поэтому это обсуждать вне контекста не имеет смысла. Тогда когда специалист столкнётся с задачаей он будет находить лучшее решение в тех технических рамках в которых он находится. Это всё банальные и достаточно очевидные вещи. Если ты хочешь это обсудить приведи пример более менее реальный и адекватный. Общественность может предложить варианты.
А.Криушин
3. Альтернатива, конечно, сомнительного качества. Но давай чуток добавим общности, ок? Кто такой этот REVERSE, если опустить мелкие детали? FBI по функции reverse. Согласен? Что мешает написать свой более разумный рандомизатор, гарантирующий уникальность, но, в отличие от reverse, использующий кучную стрельбу по группе листовых блоков вместо одного крайнего? Правда FBI - часть Data Warehousing. Но в приложении-то можно укодировать аналог? Бери свой sequence, читай из него уникальное число, правильно рандомизируй - и вуаля. Причем для этого проектировщику достаточно знать о возможной конкуренции (читай "снижении масштабируемости") и необязательности вызвавшего ее подхода к организации данных. Ну и еще немного напрячь моск :-).
Дождись 11g, там можно делать интересные вещи. Кроме того ответь на вопрос о том для чего мы используем последовательности и будет ли №3 работать в этом случае. А после этого сделай пример и посмотри сам -- он будет отличатся от приведённых выше решений, т.е. будет в каком-то плане нескольк более "дорогим" (но нужно определиться что есть "дороговизна", в данном разговоре акцент был сделан на конкуренцию в доступе, если его поменять то и оценка будет другой).
А.Криушин
PS. Народу не нужны "волшебных палочек" и "серебрянных пуль". ГЫыыы
Я не знаю кто здесь "народ"... но знать альтернативы техническим решениям, их плюсы и минусы, доводы, всё же лучше... чем разговор о том что кто-то что-то знает... знаешь и можешь доказать не только словами -- докажи. В своём случае могу сказать, не всё что я знаю я могу показать в виде примеров -- зачастую, это требует кропотливой работы (зависит от темы разговора) и здесь я сам уж выбираю когда и для кого это делать -- просто потому что всё это требует времени...
-- 
Vladimir Begun | http://alexeymazanov.narod.ru/
The statements and opinions expressed here are my own
and do not necessarily represent those of Oracle.
7 янв 07, 23:58    [3612485]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3909
Не совсем с технической точки зрения... точнее совсем не с технической...
Владимир Бегун

Маркеленков
Оба подхода имеют ряд достоинств и недостатков.

Что в предложенном варианте решения является весомым недостатком, по сравнению с обсуждаемой альтернативой? Опять же не нужно выходить из контекста обсуждаемой проблемы.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
7 янв 07, 23:59    [3612486]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3909
Apex
Не совсем с технической точки зрения... точнее совсем не с технической...
Владимир Бегун

Маркеленков
Оба подхода имеют ряд достоинств и недостатков.

Что в предложенном варианте решения является весомым недостатком, по сравнению с обсуждаемой альтернативой? Опять же не нужно выходить из контекста обсуждаемой проблемы.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options

Упс.. сорри, до конца не дочитал :)
8 янв 07, 00:01    [3612488]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Привет.
Владимир Бегун
А.Криушин
Гхммм... Я попросил бы не покушаться на мою свободу самоидентификации в этом форуме :-). Я Ааз, просто Ааз, если явно не указано иное.
Владимир Бегун
Ааз
Далее Grami привел использование global partition by hash...
Неверно! Было сказано о "hash partitioned index". Это я сделал пример на основе global индекса
О как! Разговор шел про PK/UK, да? Ты хочешь сказать, что Grami мог иметь ввиду локальный индекс? Что-то не верится.
Владимир Бегун
Далее он высказал своё собственное мнение, базированное на опыте и практике (человек проектирует биллинговые системы)
А я, значит, в основном фантазирую, как ты выразился.
Владимир Бегун
Но технически довод был верен.
Какой? Что новый костыль лучше старого, да еще придуманного совершенно по другому поводу (OPS/RAC)? Я это разве уже оспаривал?
Владимир Бегун
Далее, твоё желание технический аспект заменить финансовым в данном случае не работает... не можете использовать -- не используйте.
Не заменить, а привлечь внимание. К стоимости предлагаемого технического решения. Или, если хочешь, к оценке стоимости прокола в проектировании.
Владимир Бегун
Я сказал лиш о том что в случае наличия реальной конкуренции результат будет ещё хуже. Оно может и 2 и 3 одновременно работающих сессиях/сеансах умирать... я показал на 1; я бы мог сказать 10,20,100 -- разницы нет -- всё будет тем хуже чем больше желающих использовать этот индекс для вставок. .... В общем случае, ты проигрыш будешь получать каждую следущую секунду от простого использования (insert) обсуждаемого (reverse) индекса даже на системе с 1 пользователем -- я привёл пример.
Таки тебе удалось втянуть меня в дискуссию о сравнительных свойствах костылей :-). Ну давай разберем технические аспекты. Что block split (BS) 50:50 хуже 90:10 доказывать не надо. Это гораздо проще и убедительней посчитать на пальцах. Для REVERSE BS будет происходить в C=1.8 раз чаще. Цена BS в твоем случае, видимо, оказалась высоковатой. Да к тому же CPU на реверсирование значения. А тебя не насторожило в твоем эксперименте, что изначальное отношение 1:6 в пользу обычного индекса (пусть хешированного) всего через миллион вставок снизилось до 1:3? И знаешь, сдается мне, что домашнее задание ты выполнил спустя рукава. REVERSE проблемы с latch'ами и buffer busy решает. Понятно, что за счет чего-то. И не забывай, что перекошенные индексы имеют свойство быстрее набирать высоту. И вот когда ты запустишь одновременно много сеансов, то получишь, что кол-во столкновений на защелках будет a) зависеть от BLEVEL, b) для твоего hash будет таки существенно выше, чем для REVERSE. Так что ничего твой пример не доказал в техническом аспекте.
jdfgvdfh.f
Технически там отнюдь не все верно. Оба подхода имеют ряд достоинств и недостатков.
Ну и вернемся к изначальному.Защищаемое утверждение:
Генерация первичных/уникальных ключей через последовательность содержит избыточное свойство упорядоченности, которое необоснованно ограничивает масштабируемость приложения.
------- Конец защищаемого утверждения -------

Мдааа... Я уж даже сомневаться начал, а о том ли спор? Перечитал. Действительно - о том. О последовательности и последствиях... Разговор велся только и исключительно об этом. И как раз в этот момент был упомянут новый, добавленный в 10g костыль (так я буду продолжать считать, пока и если Grami не опровергнет, что имел ввиду именно тип индекса global partition by hash, а не что либо иное).

Само упоминание этой новой возможности содержит added value для форума. Но в контекст основного обсуждения не вписывается.

Форма выражения ... Каждый выбирает по себе.

"Костыли" ... Могут быть более или менее подходящими и даже удобными. Вот только зачем сначала зарабатывать себе геморрой, чтобы потом с ним успешно бороться?

Вообще-то был затронут более важный, нежели технические достоинства и недостатки костылей, вопрос: столь ли уместны общеупотребительные способы генерации уникальных чисел? И не стоит ли в каждом конкретном случае немного подумать?

О технических способах преодоления немасштабируемости. Имею нагло украденную из сигнатуры Mark J. Bobak цитату:
There is nothing so useless as doing efficiently that which shouldn’t be done at all. –Peter F. Drucker, 1909-2005

Всего
PS. "Народу не нужны" неужели не напомнило "Сказку от тройке"? ;-)
8 янв 07, 08:51    [3612741]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Ааз
Вот только зачем сначала зарабатывать себе геморрой, чтобы потом с ним успешно бороться?

Вообще-то был затронут более важный, нежели технические достоинства и недостатки костылей, вопрос: столь ли уместны общеупотребительные способы генерации уникальных чисел? И не стоит ли в каждом конкретном случае немного подумать?


Есть хорошее правило инженера - разумной достаточности. Говоря проще - решайте актуальные проблемы сейчас, а не пытайтесь изобрести универсальное решение всех потенциальных проблем.

Не более того. Тем более, в в вопросе поиска оптимума (который - объективно достигнут быть не может по определению, в виду неизбежной взаимозависимости критериев, говоря проще - в одном выигрываешь, в другом - проигрываешь). И на то тебе голова на плечах, абы выбрать наиболее приемлемое в данных условиях решение.

В конечном счёте, что Вы предлагаете ? Всем срочно пытаться найти и оценить наиболее универсальное решение генерации первичных ключей ?

А смысл ?

Ну кому то "нравится" GUID "распределение", кому то - хешированное, кому то же - наоборот, крайне нужны (желательны) небольшие числа кластеризации даже по ID. Методы решения проблем как бы известны, условия применения - аналогично.

И всем ли (таблицам в схеме в т.ч., вне зависимости от "масштаба" решения в целом) нужна та самая масштабируемость ?

Спор, собственно говоря, о чем ?
8 янв 07, 09:44    [3612791]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
Ты уже работаешь адвокатом? :-)

Ааз
Владимир Бегун
Ааз
Далее Grami привел использование global partition by hash...
Неверно! Было сказано о "hash partitioned index". Это я сделал пример на основе global индекса
О как! Разговор шел про PK/UK, да? Ты хочешь сказать, что Grami мог иметь ввиду локальный индекс? Что-то не верится.
Лишь только о том что ты цитируешь плохо :-). Мой довод был лишь об этом. Если ты устраиваешь разбор полётов -- будь точен.

Grami скорее всего говорил о global index, но решать эту проблему до 10g можно было и иначе. Кроме того в ракурсе того, о чём ты говорил -- о том что таблица тоже может быть партиционирована, hash мог иметь и другой смысл, поэтому я и предложил поразмыслить как ты эту проблему будешь решать в случае reverese index. А ты как-то ушел от ответа :-) Покажешь как? :-)

Ааз
Владимир Бегун
Я сказал лиш о том что в случае наличия реальной конкуренции результат будет ещё хуже. Оно может и 2 и 3 одновременно работающих сессиях/сеансах умирать... я показал на 1; я бы мог сказать 10,20,100 -- разницы нет -- всё будет тем хуже чем больше желающих использовать этот индекс для вставок. .... В общем случае, ты проигрыш будешь получать каждую следущую секунду от простого использования (insert) обсуждаемого (reverse) индекса даже на системе с 1 пользователем -- я привёл пример.
Таки тебе удалось втянуть меня в дискуссию о сравнительных свойствах костылей :-). Ну давай разберем технические аспекты. Что block split (BS) 50:50 хуже 90:10 доказывать не надо. Это гораздо проще и убедительней посчитать на пальцах. Для REVERSE BS будет происходить в C=1.8 раз чаще. Цена BS в твоем случае, видимо, оказалась высоковатой. Да к тому же CPU на реверсирование значения. А тебя не насторожило в твоем эксперименте, что изначальное отношение 1:6 в пользу обычного индекса (пусть хешированного) всего через миллион вставок снизилось до 1:3? И знаешь, сдается мне, что домашнее задание ты выполнил спустя рукава. REVERSE проблемы с latch'ами и buffer busy решает. Понятно, что за счет чего-то. И не забывай, что перекошенные индексы имеют свойство быстрее набирать высоту. И вот когда ты запустишь одновременно много сеансов, то получишь, что кол-во столкновений на защелках будет a) зависеть от BLEVEL, b) для твоего hash будет таки существенно выше, чем для REVERSE. Так что ничего твой пример не доказал в техническом аспекте.

:-) Я специально опустил детали, чтобы дать специалистам, которые "знают" возможность подумать... Приведи мне пожалуйста пример, показывающий все те проблемы, которые ты описал выше -- пример когда для одной или более сессий выполняющих массивные операции вставки с использованием последовательности reversed индекс выиграет в производительности хотя бы на n% (n > 10) по сравнению с хэш решением. А домашнее задание я выполнил хорошо, ты скоро сам это поймешь. В следущей (или через одну) итерации -- я опубликую скрипт у себя в блоге.
8 янв 07, 09:48    [3612798]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
Ааз
И вот когда ты запустишь одновременно много сеансов, то получишь, что кол-во столкновений на защелках будет a) зависеть от BLEVEL, b) для твоего hash будет таки существенно выше, чем для REVERSE.

:-)
    BLEVEL LEAF_BLOCKS
---------- -----------
         1         243
         1         242
         1         242
         1         242
         1         242
         1         243
         1         242
         1         242

8 rows selected.

SQL>
    BLEVEL LEAF_BLOCKS
---------- -----------
         2        2471
Главное здесь -- число степеней свободы, у меня их 2^n, а у тебя? :-)
8 янв 07, 10:27    [3612842]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Grami
Member

Откуда: Москва
Сообщений: 451
Ааз
И как раз в этот момент был упомянут новый, добавленный в 10g костыль (так я буду продолжать считать, пока и если Grami не опровергнет, что имел ввиду именно тип индекса global partition by hash, а не что либо иное).


А вот и я.

Я имел в виду следующее:
1. Существует инструмент, не изменяющий логику приложения, который позволяет избежать того, что в работающей системе, при генерации первичных/уникальных ключей через последовательность, проявляется
Ааз

избыточное свойство упорядоченности, которое необоснованно ограничивает масштабируемость приложения.


2. Этот инструмент называется hash partitioning

3. Начиная с версии 10g, когда появилась возможность создания индексов global partition by hash, этот инструмент стал универсальным при решении подобным проблем (для EE). Если при этом логика приложения не допускает использования глобальных индексов, например, как уже было замечено для проведения partition maintenance операций, то возможность hash partitioning тут не при чём.

Ааз

О как! Разговор шел про PK/UK, да? Ты хочешь сказать, что Grami мог иметь ввиду локальный индекс? Что-то не верится.

С чего бы это? Телепаты вроде в отпуске... =)
Мог иметь в виду, и имел.
У нас на production (Oracle 9.2.0.7) есть таблица с composite partitioning: range-hash по первичному ключу, генерируемому по последовательности. Индекс на PK - локальный. Отдельно замечу, что таблица и индекс не создают заметных проблем с latch'ами и buffer busy, при том что в таблицу происходит вставка 500-700 записей в секунду из 30-50 активных сессий. Заявленной избыточной сериализации нет.
8 янв 07, 12:34    [3613045]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
Grami
С чего бы это? Телепаты вроде в отпуске... =)
:-) Ну, я ж говорил... всё решается, если думать и для 10g и не для 10g... главное понимать в чём проблема...

Андрей, жду сценарии... напрягите там "моск" с коллегой у которого nickname меняется. :-) Интересно всё же увидеть "ряд недостатков". :-)
8 янв 07, 12:47    [3613072]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
grexhide
Есть хорошее правило инженера - разумной достаточности. Говоря проще - решайте актуальные проблемы сейчас, а не пытайтесь изобрести универсальное решение всех потенциальных проблем.
Кто и где в этом треде говорил об универсальном решении? Говорили о последовательностях. Это тема номер раз. Потом возникла тема технических решений для устранения/снижения последствий применения последовательности. Это тема номер два.

По первой высказана рекомендация просто подумать о возможной конкуренции, а не юзать сиквесы по умолчанию. Считаете, что это неуместно? :-) Па добраму, канешна.

Решать актуальные проблемы сейчас - хорошее правило для таких консалтеров, как я. Reactive tuning называется. Ибо поезд уже ушел, архитектуру приложения переделывать поздно, или слишком накладно, или то и другое вместе. Грабли про стандартные решения известны, и их немного. А еще говорят, что в природе встречается proactive. Кому как не архитектору/проектировщику прикинуть на основе своего представления о характере использования тех или иных структур потенциально подверженные известным граблям места?

grexhide
Спор, собственно говоря, о чем ?
Не об изобретении универсальных рецептов. Зуб даю ;-).

Всего
8 янв 07, 12:53    [3613090]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Владимир Бегун

    BLEVEL LEAF_BLOCKS
---------- -----------
         1         243
         1         242
         1         242
         1         242
         1         242
         1         243
         1         242
         1         242

8 rows selected.

SQL>
    BLEVEL LEAF_BLOCKS
---------- -----------
         2        2471
Главное здесь -- число степеней свободы, у меня их 2^n, а у тебя? :-)
У тебя здесь (будет при ~16 одновременно активных сеансов) 8 перманентно перегретых блоков (leaf) как по защелкам, так и по buffer busy. И это тот самый минус. Шагнешь уровнем ниже - получишь еще 8 перманентно подогретых brach. Там забавно будет - конкурирующий перец прется в листовой блок, который в данный момент делится. И 8 root'овых, что таки плюс, но не уверен, что в 10g достаточно заметный. У твоего REVERSE (не у меня, не надо ля-ля :-)) 2471 перманентно холодных блока. Согласен, что root всегда "горячий". Однако ейный latch хватается в shared-режиме, сам блок ...ммм... тут надо потестить. А моя VMWare с тестовой 10.2.0.2 и 10.2.0.3 слита с лаптопа. Не уверен, что ... не будет buffer busy. Хотя вот с записываемыми DBWR'ом блоками порешали еще в 9i путем клонирования... Очевидно, что кол-во листовых дойдет до невмещаемости в кеш буферов, в чем и заГлючается Клавный недостаток. Другой, типа второстепенный уже обговорен - блок сплит.

Володя, раз уж у тебя все уже заточено - ты не мог бы свои же тесты прогнать без ASSM и с freelist'ами . Ну и, там, INITIAL поставить куда подальше? А то ХЗ, что за числа ты намерял по перформансу.

Владимир Бегун
А ты как-то ушел от ответа :-)
У нас, видишь ли, новогодне-рожденственские каникулы. Думаешь, с чего я так на форуме расписался :-). Работать неохота да и дела есть домашние, хотя пришлось уже в НГ один раз напрячься, и один раз к клиенту съездить прямо на Рождество на ... ммм.. номер отбыть.

Всего
8 янв 07, 13:53    [3613222]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Ааз
Кто и где в этом треде говорил об универсальном решении? Говорили о последовательностях. Это тема номер раз. Потом возникла тема технических решений для устранения/снижения последствий применения последовательности. Это тема номер два.

Ну... мне так показалось ;) Я и сам подумал - чего это я...

Ааз

По первой высказана рекомендация просто подумать о возможной конкуренции, а не юзать сиквесы по умолчанию. Считаете, что это неуместно? :-) Па добраму, канешна.

Думать о конкуренции (да и не только) нужно всегда. Но на самом деле - проще отработать технические решения заранее, и уже просто ходить в "меню" оных.

Ааз

Решать актуальные проблемы сейчас - хорошее правило для таких консалтеров, как я. Reactive tuning называется. Ибо поезд уже ушел, архитектуру приложения переделывать поздно, или слишком накладно, или то и другое вместе. Грабли про стандартные решения известны, и их немного. А еще говорят, что в природе встречается proactive. Кому как не архитектору/проектировщику прикинуть на основе своего представления о характере использования тех или иных структур потенциально подверженные известным граблям места?


reactive/proactive..... знал бы где упасть...

Впрочем, реверсные индексы и хешированное партицирование индексов - как раз и похоже на то самое средство решения проблем в условиях "ушедшего поезда"

При прочих же равных условиях - тривиальное (вернее управляемое вручную) конкатенирование тех же глобальных PK от конкатенации чего то там (хеша сессии, хеша ноды, и вообще и т.д.) с полученным значением последовательнсостии вполне решает себе необходимую степень масштабируемости и управляемости (в избавлении от перегретости).

Вопрос в другом (а бревна то в глазу я и не заметил..)... что при прочих равных условиях, хотелось бы, конечно иметь какой либо достаточно простой (подобный freelists/freelist groups) механизм получения сиквенса от заранее определенных диапазонов (абы попасть в нужную тебе группу блоков)...

Плюс - какой либо механизм, чуть более продвинутый, чем автономную транзакцию на одну едниственную запись в словаре... А почему бы и нет ? Да, именно, группы- диапазоны на сиквенсах, с аналогичным механизмом привязки от хеша ноды и сессии (просто, абы не плодить при случае наборы этих сиквенсов).

Но раз нельзя - значит нельзя (доктор сказал кодировать конкатенации или реверсировать/хешировать - значит будем хешировать или реверсировать ;))
8 янв 07, 14:14    [3613261]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Владимир Бегун


Кстати, Владимир, а вот можно отвлечённый вопрос ?

В Oracle есть какой либо механизм принятия/рассмотрения предложений от простых смертных на Feature Request-ы в Oracle RDBMS.

--

А то вот незадача, все будоражит сознание предложение по организации, к примеру, параметризованных VIEW через обращение к переменным пакета (пакета, а не тела) аки BIND переменных....

Не ахти какая сложность, а всяк было бы приятно (хоть услышать вежливый отказ под видом : "мы рассмотрим ваше предложение").
8 янв 07, 14:20    [3613274]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
grexhide
Владимир Бегун


Кстати, Владимир, а вот можно отвлечённый вопрос ?

В Oracle есть какой либо механизм принятия/рассмотрения предложений от простых смертных на Feature Request-ы в Oracle RDBMS.

+1. Вот эту багу б зарепортил :) А то некрасиво: в плюсе одно, в ждбц другое...

Хотя баг репортинг от "простых смертных" попахивает опен сорсом, да и ресурсы на это нужны (и немалые)...
8 янв 07, 15:02    [3613341]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
asdfghjkl
Guest
Владимир Бегун
Я повторяю: реплика Grami технически более верная в контексте разговора, чем словесные изыски по-поводу "слабостей".
Ты видишь один "контекст разговора", я другой, кто-то - третий. Мои "словесные изыски" касались только двух процитированных абзацев, и в первую очередь - второго. Все остальное - притянутое тобой за уши.

Владимир Бегун
Что в предложенном варианте решения проблемы неверно, только обоснованно не выбиваясь из контекста и не разглагольствуя?
Что касается "проблемы" и "контекста" - см. выше. Поэтому подстилать себе соломки этим и "запретом разглагольствования"... Право, смешно. В очередной раз.

1. "Конкуренция за листовой блок в этом случае легко устраняется..." - она не устраняется, а заменяется конкуренцией за 8/16/etc листовых блоков. То есть, лишь уменьшается в N раз. Под конкуренцией за листовой блок ведь подразумеваются buffer busy waits, не так ли? Реверсивный индекс полностью устраняет именно эту проблему.

2. "Конкуренция за листовой блок в этом случае легко устраняется..." - про EE уже упомянуто. Кроме того, в рамках "контекста обсуждаемой темы", речь о секционировании таблицы не шла вообще. Учитывая необходимость в подавляющем большинстве случаев для использования секционирования соотв. образом проектировать приложение, а также фразу "на мой взгляд начиная с версии 10g возможность создания таких индексов присутствует для обратной совместимости, не более", можно прийти к выводу, что Grami имел ввиду именно глобальные хэш-секционированные индексы. Ведь все это поняли именно так, не правда ли? То есть, нужен Oracle 10.1 и выше. Реверсивные индексы, если не изменяет память, появились в 8.0.

3. Что касается "P.S. Считаю reverse index неудачной сущностью в субд Oracle, на мой взгляд начиная с версии 10g возможность создания таких индексов присутствует для обратной совместимости, не более.". Именно эта фраза и вызвала крайне негативную (возможно, излишне негативную - но я здесь зачастую груб, особенно с незнакомыми мне людьми - имеют место быть деструктивные изменения личности после общения на данном форуме. При личном общении я пока добр и корректен :) ) реакцию. Ну, и фраза "Приятно читать посты человека, разбирающегося в предмете" как мне показалось, была добавлена как бы в оправдание последующего после этого "опускания" Ааза.

IMHO, все эти "личные мнения" о ненужности чего-либо (ненужность buffer pool keep/recycle, индексных и хэш-кластеров etc) и приводят к "дебилизации" каждой новой версии Oracle. Особенно, когда это звучит из уст человека, который "проектирует биллинговые системы" - результаты работы некоторых таких "проектировщиков" (я не имею ввиду конкретно Grami) многие видят и кроют матом.


Владимир Бегун
Что в предложенном варианте решения является весомым недостатком, по сравнению с обсуждаемой альтернативой? Опять же не нужно выходить из контекста обсуждаемой проблемы.
Я не увидел здесь никакого описания "проблемы". Тот или иной способ применим в зависимости от конкретных условий. Или тебе про "достоинства и недостатки" хочется послушать, ждешь, вдруг что-нибудь не то ляпну? :)

Безусловно, при хэш-секционировании 99% всех расщеплений листовых блоков будут 90/10 (точнее - 100/0, т.е. фактическое отсутствие). Хотя легко привести пример работы приложения, когда до 50% расщеплений будут 50/50 (абстрагируемся от IOT, где расщепление почти везде по месту вставки), а оставшаяся половина - 90/10 . При этом каждый листовой блок будет заполнен только наполовину до очередного rebuild/coalesce. В реверсивном индексе такого случиться практически не может. "Чтобы дать специалистам, которые "знают" возможность подумать", "сценарий" приводить не буду - ты тоже напряги свой "моск" :)

Хэширование требует немалого количества CPU, согласно моим когда-то проведенным экспериментам - больше, чем реверсирование. Конечно, если создать составной индекс по (a number,b varchar2(200),..) и его хеш-секционировать только по a, он конечно выиграет в потреблении CPU у составного реверсивного индекса. Но это от того, что реверсивные индексы до сих пор "недоделанные" - не помешала бы фраза reverse(a). Как там в 11g? :)

Если вспомнить, что некоторые приложения выполняют вставку массивом, то оба варианта (хэш/reverse) - полное говно. При этом своя функция, добавление к номеру последовательности некоего своего значения etc дают возможность упорядочить данные перед вставкой массивом. Хэширование - формально да, но вы не публикуете используемый алгоритм хэширования, ведь это такая военная тайна, "запатентованная фича" и т.д. Поэтому на практике при хэшировании невозможно предварительное упорядочивание данных для повышения производительности.

Что касается возможности range scan хэш-секционированного индекса при поиске по диапазону, то да, она имеется. Но все хорошо, пока число секций невелико, т.к. range scan 32/64/128 секций запросто может оказаться хуже, чем IFS, IFFS или FTS. Тогда грош-цена такой возможности.

Подобно freelists/freelist groups и ASSM, при хэш-секционировании крайне желательно создать достаточное (оптимальное) число секций, для чего нужно приблизительно знать число одновременно вставляемых данные сеансов. Реверсивный индекс в данном случае подобен ASSM - автоматическая рандомизация :)

Кроме команд insert бывают еще другие команды. И вероятность нарваться select'у на buffer busy waits при хэш-секц. гораздо выше. И не факт, что db file sequential read в случае реверсивного индекса перевесят, особенно если буф. кэш баааальшой и старые строки достаточно быстро удаляются :)

Это все, что навскидку пришло на ум. Можно еще что-нибудь вспомнить, но ты ведь снова обвинишь в раглагольствовании, демагогии, отходе от темы и пр. :)

Разумеется, у реверсивных индексов есть несколько существенных недостатков - надеюсь, перечислять не надо? :). Замечательно, что есть хэш-секционирование, но сбрасывать, как некоторые, со счета реверсивные индексы еще рано.

Владимир Бегун
Говорить банальности "Оба подхода имеют ряд достоинств и недостатков" -- это наивно, когда просто нужно сравнить два момента на которые было указано (возможности сравнений и уменьшени i/o).
Это ты придумал эти "два момента", ни о чем таком я речь не вел.

Владимир Бегун
знаешь и можешь доказать не только словами -- докажи. В своём случае могу сказать, не всё что я знаю я могу показать в виде примеров -- зачастую, это требует кропотливой работы (зависит от темы разговора) и здесь я сам уж выбираю когда и для кого это делать
Я здесь никому не обязан ничего доказывать. В том числе и по указанной тобой причине.


И еще. Пожалуйста, не надо приписывать слова одних граждан другим гражданам, ибо принадлежность слов может оказаться лично твоим домыслом, коих (домыслов) ты не любишь слышать от других, но пользуешь сам направо и налево :)

Адвокатов мне не надо, гражданин прокурор :)
Bye.
8 янв 07, 20:33    [3613774]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
asdfghjkl
...
:-) Жаль, жаль, что нам так и не удалось выслушать начальника транспортного цеха... Вы хотя бы 10 процентов выигрыша выбейте на 8 конкурентных сеансах... Пока всё то что ты сказал в одной итерации -- это в основном повтор (с более эмоциональной окраской), того с чем выступил твой коллега выше в трёх.
8 янв 07, 21:01    [3613796]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Beholder
Guest
Владимир Бегун
asdfghjkl
...
:-) Жаль, жаль, что нам так и не удалось выслушать начальника транспортного цеха... Вы хотя бы 10 процентов выигрыша выбейте на 8 конкурентных сеансах... Пока всё то что ты сказал в одной итерации -- это в основном повтор (с более эмоциональной окраской), того с чем выступил твой коллега выше в трёх.

Однако, какой символичный номерок у поста...:)
Парни, продолжайте, я аж прям зачитался....
8 янв 07, 21:11    [3613807]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
1. "Конкуренция за листовой блок в этом случае легко устраняется..." - она не устраняется, а заменяется конкуренцией за 8/16/etc листовых блоков. То есть, лишь уменьшается в N раз.
Где N прогнозируемо и может быть выбрано заранее, зная о нагрузке системы.

Реверсивный индекс полностью устраняет именно эту проблему.

:-) Зато вносит ряд других, которые значительно сложнее решить.

2. "Конкуренция за листовой блок в этом случае легко устраняется..." - про EE уже упомянуто. Кроме того, в рамках "контекста обсуждаемой темы", речь о секционировании таблицы не шла вообще.
О секционировании разговор начал твой коллега. Перечитай внимательно всю нитку разговора -- в моём примере таблица обычные и сравниваемы индексы именно такие о каких шла речь в процитируемом абзаце, который ты так эмоционально раскритиковал.

3. Что касается "P.S. Считаю reverse index неудачной сущностью в субд Oracle, на мой взгляд начиная с версии 10g возможность создания таких индексов присутствует для обратной совместимости, не более.". Именно эта фраза и вызвала крайне негативную (возможно, излишне негативную - но я здесь зачастую груб, особенно с незнакомыми мне людьми - имеют место быть деструктивные изменения личности после общения на данном форуме. При личном общении я пока добр и корректен :) ) реакцию. Ну, и фраза "Приятно читать посты человека, разбирающегося в предмете" как мне показалось, была добавлена как бы в оправдание последующего после этого "опускания" Ааза.
С этим, пожалуйста, к психологу.

Владимир Бегун
Что в предложенном варианте решения является весомым недостатком, по сравнению с обсуждаемой альтернативой? Опять же не нужно выходить из контекста обсуждаемой проблемы.
Я не увидел здесь никакого описания "проблемы".
Я привёл тестовый пример, который однозначно показывает суть проблемы. Что ещё нужно увидеть?

Подобно freelists/freelist groups и ASSM, при хэш-секционировании крайне желательно создать достаточное (оптимальное) число секций, для чего нужно приблизительно знать число одновременно вставляемых данные сеансов.
Можно подумать проблема это выяснить и/или перестроить индекс, если станет понятно что всё плохо. Что ты сделаешь в случае reverse индекса?

Кроме команд insert бывают еще другие команды. И вероятность нарваться select'у на buffer busy waits при хэш-секц. гораздо выше.
Докажи. Пример создания таблиц/индексов приведён.

Владимир Бегун
Говорить банальности "Оба подхода имеют ряд достоинств и недостатков" -- это наивно, когда просто нужно сравнить два момента на которые было указано (возможности сравнений и уменьшени i/o).
Это ты придумал эти "два момента", ни о чем таком я речь не вел.
Да, ты не вёл, ты просто ляпнул... :-)

И еще. Пожалуйста, не надо приписывать слова одних граждан другим гражданам, ибо принадлежность слов может оказаться лично твоим домыслом, коих (домыслов) ты не любишь слышать от других, но пользуешь сам направо и налево :)
Я ничего никому не приписывал, я предложил сравнить два метода -- был приведён сценарий. Весь остальной разговор я вёл не с тобой а с твоим коллегой.
8 янв 07, 21:30    [3613830]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
Beholder
Парни, продолжайте, я аж прям зачитался....
:-) Интересно всё ж увидеть цифры, пока всё буквы, да буквы...
8 янв 07, 21:34    [3613835]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
есть и существенные ограничения на предложенный в качестве "полноценной замены" реверсивного индекса способ. Я знаю по крайней мере бОльшую часть достоинств и недостатков обоих методов, а Grami - либо нет, либо скромно умалчивает. Уверен в первом.

Что есть "существенные ограничения на предложенный в качестве "полноценной замены" реверсивного индекса способ."? Я не увидел ни одного технически грамотно изложенного довода ни об одном из существенных технических ограничений, не было приведено ни одно сценария, хотя бы косвенно иллюстрирующего проблему и приемущества реверсивного индекса по сравнению с тем хэш индексом. Хотелось бы увидеть хотя бы один.
8 янв 07, 21:42    [3613844]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
grexhide
Владимир Бегун


Кстати, Владимир, а вот можно отвлечённый вопрос ?

В Oracle есть какой либо механизм принятия/рассмотрения предложений от простых смертных на Feature Request-ы в Oracle RDBMS.

Это назвается Enhancement Request (ER). Я не уверен что для "простых смертных" -- подразумевается наличие тех. поддержки. Я незнаю настоящего процесса, но подразумеваю что стоит открыть tar и обсудить этот момент. Я знаю что Oracle рассматривает/-вал очень многие ER на конференциях http://www.ioug.org/ там был какой-то комитет.

[OFFTOPIC]
grexhide
А то вот незадача, все будоражит сознание предложение по организации, к примеру, параметризованных VIEW через обращение к переменным пакета (пакета, а не тела) аки BIND переменных....
А чем контексты не устраивают?

grexhide
Не ахти какая сложность, а всяк было бы приятно (хоть услышать вежливый отказ под видом : "мы рассмотрим ваше предложение").
Я боюсь что в данном случае тебя всё же попросят рассмотреть использование контекстов.
[/OFFTOPIC]
8 янв 07, 21:59    [3613858]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
[OFFTOPIC]
Timm
+1. Вот эту багу б зарепортил :) А то некрасиво: в плюсе одно, в ждбц другое...
Это вроде как стандартный механизм -- нужно открыть tar. Я могу открыть баг, но в этом случае ты не сможешь его мониторить. Мне нужен будет test-case -- коротенький пример на java/jdbc иллюстрирующий проблему. Почтовый адрес в профиле.

А setEscapeProcessing тебя не спасает?
[/OFFTOPIC]
8 янв 07, 22:07    [3613865]     Ответить | Цитировать Сообщить модератору
 Re: автоматический инкремент в оракле  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
[OFFTOPIC]
Владимир Бегун

Это назвается Enhancement Request (ER). Я не уверен что для "простых смертных" -- подразумевается наличие тех. поддержки. Я незнаю настоящего процесса, но подразумеваю что стоит открыть tar и обсудить этот момент. Я знаю что Oracle рассматривает/-вал очень многие ER на конференциях http://www.ioug.org/ там был какой-то комитет.

Да, извиняюсь за первоначально глупый вопрос, просто я слегка растерялся со своими правами (лукера ;) на металинке. Буду пинать администратора ;)

Владимир Бегун

А чем контексты не устраивают?


Примерно вот этим (если говорить про производительность)

SQL> SELECT sum(ID + PTEST.GET_VALUE) FROM BIG_TABLE; -- вызов через PL/SQL функцию
Executed in 5,067 seconds


SQL> SELECT sum(ID + sys_context('PTEST', 'VALUE')) FROM BIG_TABLE; -- вызов через контекст
Executed in 0,981 seconds

SQL> SELECT sum(ID + :PTEST_VALUE) S FROM BIG_TABLE; -- идеальная ситуация
Executed in 0,36 seconds

---- А хотелось бы просто, по подобию курсоров в PL/SQL, рассматривая PTEST.VALUE
---- как константу или переменную пакета

SQL> SELECT sum(ID + PTEST.VALUE) FROM BIG_TABLE; 
ORA-06553: PLS-221: 'PTEST.VALUE' is not a procedure or is undefined


Т.е. такое ощущение, что sys_context вызывается для КАЖДОЙ записи, а это - нежелательно

Не считая еще и вопросов с преобразованием типов (только VARCHAR2 в SYS_CONTEXT), ну и аспектами удобства (позднее связывание и синтаксис....)

[/OFFTOPIC]
9 янв 07, 03:28    [3614091]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Oracle Ответить