Уважаемые администраторы Cache и разработчики!

Разработана Автоматизированная Система Контрольных Расчетов
для крупного телекоммуникационного предприятия. Ядро ее
составляет база под Oracle9i. В последнее время база
не выдерживает нелинейного роста количества хранимых
услуг. Дело в том, что таблица, в которой хранятся услуги ( service )
имеет древовидную структуру. Т.е. услуга с кодом ID1 может
быть контейнером для услуг ID2... и т.д. В процессе загрузки
данных в таблицу услуг (или построения отчетов), возникают
таймауты чтения строк из таблицы service . Это следует
из трассировочных файлов.

Ведущие разработчики и ДБА сделали фактически все, что могли.
(выделили отдельный SCSI-диск для service, создали необходимые
индексы, добавили соотв. хинты к запросам). Однако, достигнут
технологический предел возможностей Oracle. У нас хватает
силы духа признать, что целевая СУБД неэффективно работает
и иерархическими структурами. И это было подтветждено неоднократно.

Когда кризис достиг апогея, по управлению поползли слухи.
Дескать Оракл неэффективен... зачем надо было платить десятки
тысяч и.т.п. На оперативках звучали провокации. Появились разработчики-проходимцы, которые заявили, что СУБД вообще не нужна... можно
создать XML-хранилище файлов и.т.п. бред.

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

Речь конечно не идет о миграции задачи на Cache. Это невозможно
в данный момент. Однако стратегия развития
позволяет (и поощряет) создание сети дешевых серверов приложений
второго звена, которые могли-бы взять на себя часть специфичных задач
сервера БД, распределив, таким образом нагрузку.

Я активно лоббирую процесс создания сервера(ов) 2 звена,
под Cache. однако имею целый ряд нерешенных вопросов.

1) Каким образом можно интегрировать Oracle и Cache?
Можно-ли использовать db-link? Кого следует назначить
клиентом?

2) Насколько сильно придется переделывать SQL-ный
код для поддержания полиморфизма с ракурса
PL-SQL-бизнес-логики?

3) Как гарантировать транзактивную целостность в такого
рода системах? Существуют-ли соотв механизмы?

Я обращаю свое внимание на Cache потому-как из литературы,
статей, обзоров следует, что задачи где имеет место
интенсивная нагрузка на иерархическу структуру
Cache решает наиболее эффективно. Еще раз повторю,
что перенос всей базы под Cache - невозможен. Слишком
много средств было вложено в создание первого решения.
Слишком много кода написано и слишком много людей
получают зарплату от программирования на PLSQL.

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

Спасибо.

2 Квасов

Да.. история трогательная. На самом деле, там не один
диск а Raid 1+0.

Дело не в ОЗУ а в архитектуре. Если вы считаете, что
покупка кластера решит проблемы, то вы скорее всего
ошибаетесь. Пока-что мы надеемся, что техника будет
развиватся по закону Мура (и так-же быстро падать в
цене ) в противном случае, наша база вылетит в
трубу. Кроме того .. муссирование этой тематики
в кулуарах порождает волну негодования особенно
от тех самых разработчиков-конкурентов, которые
выдвигают свои (как они считают) дешевые решения
проблемы.
Так что нам остается молча терпеть и думать над
тем, как подкрутить еще пару гаек в Oracle и заставить
его хоть немножко бегать быстрее по деревьям.

В настоящий момент железка такая:
4xXeon/ 8Gb / SCSI Fiber Channel хранилище на 1 Tb.

Благодарю вас за ссылку. Но у нас уже есть свой поставщик
оборудования.

kvasov
у вас нет dimm разьемов – вот ваша проблема

и вот здесь появляется некое новое слово NUMA Link архитектура, что это такое еще до конца не ясно, какой-то порт новый в мат плате, суть в том, что по нему пристегивается 2-ая матплата, в которой одно озу – нет ни процессора и вообще ничего более – банк озу.

а в программах ничего не меняется – была 1ос и 1программа и они же и остались – то есть логически это 1 комп.


Что это за порт? Какие чипсеты его поддерживают?

Насколько решение надежно?

Есть ли тесты перформанса?

(cо вздохом)

Читайте мои вопросы в первом посте. За кулуарность ... извините.
Наболело просто.

Мы думали об этом. Группу подчиненных полей предлагалось
заменить на XMLTYPE. Однако ... здесь неясно, как
быть с бизнес-логикой. Половину кода переписать
придется. Да и с блокировками .. тоже больше вопросов,
чем ответов.

Ладно.. в субботу я предоставлю статистику
по этой таблице (кол-во строк, поля, глубину
вложенности).