Oracle, как религия

    Всё, что написано ниже, относится к Oracle Database и Oracle Exadata.

    Преамбула



    Полная луна освещала пыльную, петляющую дорогу, исчезающую среди холмов впереди. Я стоял в раздумье в начале своего пути, размышляя о том, куда может привести эта дорога. Отбросив сомнения прочь, я начал свой путь к виднеющейся вдалеке пирамиде, вершина которой терялась среди облаков. По дороге мне никто не встретился, кроме памятника, больше похожего на надгробие с изображением человека и надписью огромными буквами “In Codd we trust”. Подойдя к пирамиде на достаточно близкое расстояние, я сумел разглядеть, что она состоит из DB_BLOCK-ов, большей частью размером 8Kb, но можно было найти и больше. На каждом блоке был изображен логотип компании, которая использовала блок для хранения своих данных. Заметив небольшую толпу около входа в пирамиду, я заинтересовался, и решил узнать, что это такое. Подойдя совсем близко, толпа приобрела очертания – большой частью она состояла из студентов, но встречались и бизнес-аналитики, тестеры, программисты, можно было даже заметить пару менеджеров по продажам – все они рвались внутрь.

    Проскользнув через незаметную щель рядом с главным входом, я очутился в удивительном месте. Огромное пространство было заполнено искрящимися данными, стены покрыты AWR снимками и лозунгами. Некоторые из них были для меня непонятны, а некоторые хорошо знакомы – “Exadata быстрее X в 6 раз”,”Oracle быстрее Y в 16 раз”,”Oracle БЫСТРЕЕ!!!”,”RAC – наше всё!”,”Back up or not back up? – choose your death”,”No backup – no luck!”,”ASM – дорога в будущее”,”DataGuard – make life easier!”. Публика внутри несколько отличалась от той, что была снаружи. Программисты всех направлений и мастей, руководители проектов, архитекторы, аналитики, консультанты, интеграторы – все они нашли прибежище внутри огромной пирамиды. Тут же были и евангелисты, невнятно и быстро что-то говорившие, повышая голос и интонацию при слове Oracle. Оглядевшись внимательнее, я заметил несколько групп людей, не имеющих лихорадочного блеска в глазах, которых передергивало при слове Oracle. Это группа людей в рубашках корпоративного синего цвета с надписью Microsoft и табличкой SQL Server. Они плакали в бессильной злобе, тихо бормоча “У нас тоже есть MVCC, просто оно не включено по дефолту”. Чуть подальше от них, находились палатки с надписью PostgreSQL – суровые ребята в черных балахонах, недоверчиво смотрящие на все происходящие вокруг и продолжающие заниматься своим делом. Жаль, Стоунбрейкер оставил их. Переведя взгляд дальше, я увидел флаги IBM и DB2 – группа людей в круглых очках, полностью закрывшаяся от всех остальных мэйнфрэймами. Они находились в некоем непонятном трансе, создавалось впечатление, что они не понимают, что происходит вокруг. В их странных Вселенных параллельные прямые пересекались, а перпендикуляр имел отрицательное значение.

    Немного освоившись, я убедился, что самое интересное находится в центре пирамиды, и направился туда. Именно там несла свое служение каста жрецов под названием DBA. Каста имела три уровня, по степени благословления от Oracle, и располагалась в соответствующем порядке. Внизу холма, состоящего из бэкапов, находились послушники в красных балахонах c большими буквами OCA на спине – размахивая мануалами, они заучивали случаи, когда необходимо использовать bitmap индекс, а также, чем nested loop отличается от hash join-a. Чуть повыше, на подножии, стояли адепты в желтых балахонах с надписью OCP. Они держали в руках свитки с SQL и RMAN скриптами, заучивая их наизусть, а особо сложные и красивые откладывали в стороны или обменивались ими с соседями. На середине холма сидели жрецы OCM в черных балахонах, давно постигшие дао Oracle, они мудро кивали головами, и снимали бэкапы силой мысли, а производительность оптимизировали наложением рук.

    Чуть повыше, на импровизированной сцене, Том Кайт умело объяснял заповеди Oracle, одной рукой швыряя в толпу металинковские ноты, а другой рукой ведя блог в Интернете. На самой вершине холма располагался трон, на котором восседал солнцеподобный Ларри Эллисон. В левой руке он держал уменьшенную копию Exalytics, в правой Exadata, а сам он восседал на Big Data Appliance. Громко стучали сотни барабанов, отсчитывая постоянно растущий SCN. Время от времени Ларри поднимал то одну, то другую руку, указывая мэйнстрим развития баз данных, при этом толпы маркетологов и последователей, радостно вопя, поддерживало его начинания.

    Ища мудрости и знания, я добрался до получения заветного желтого балахона и получил привилегию создавать свои свитки, обсуждать ORA-00600 и ORA-12704, притронутся к RMAN и Data Guard и многое другое. Я постиг дао реляционной модели, впитал в себя принципы ACID, познал инь данных и ян транзакций. Я по праву занял свое место и знал все смещения в datablock header-e.

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

    Мне в спину неслись маркетинговые выкрики, потрясание мануалами, сладкие обещания HR – но я лишь ускорял свой бег, пелена спала с моих глаз, и все вокруг превратилось в жуткий кошмар. Очнувшись на зеленой поляне, я остановился, оглянулся вокруг и постарался оценить мой предыдущий опыт.

    Фабула



    Недавно, находясь на конференции, я имел мимолетное знакомство с коллегами из сходной области, где сейчас работаю я. Во время обсуждения платформы, представленной на этой конференции, коллега, пытаясь показаться остроумным, высказал фразу «Exadata для бедных», имея в виду как раз обсуждаемую платформу. Половина поддержала это высказывание одобрительным смешком, а я понял, что все те деньги, затрачиваемые Oracle на маркетинг, потрачены не зря, и Exadata превратилась в брэнд. Ну как же, я захотел сказать, вы можете любить и молиться на Oracle, если он наплевал на один из принципов ACID? И даже может потерять commit — Ссылка

    Постоянно встречаюсь с людьми, имеющими зашоренный взгляд на Oracle, думающими, что Oracle может решить все проблемы и утверждающими, что Oracle – это лучшее из лучшего. В той среде, где обитает Oracle, такие настроения внедрены повсеместно и напоминают скорей религиозное поклонение, чем профессиональное использование инструмента. Почему бы не разобраться, где Oracle действительно лучший, а где нет? В чем у меня лично нет сомнений, так это в том, что в маркетинге Oracle действительно лучший. Тому есть масса примеров, из последнего я видел рекламный баннер в Шереметьево, объявляющий, что Oracle во сколько-то раз быстрее HP. Oracle использовала этот слоган против всех конкурентов – это грязный пиар, что именно Oracle декларировала, можно увидеть на картинках ниже. Причем, перед всеми Oracle пришлось извиниться и забрать свои слова обратно – но шум-то уже произошел, цели достигнуты – все услышали про Exadata.









    Соглашусь с тем, что Oracle – это лучшее решение по функциональности в OLTP сфере – тут трудно поспорить, и я даже сам посоветую каждому использовать Oracle. Богатые функциональные возможности – бэкапы, standby, партиционирование, RAC, ASM, Flashback, MVCC и многое-многое другое давно сделали его лидером в этом сегменте. Кто-то захочет упомянуть PL/SQL – вот тут уже есть место для спора, так как использование бизнес логики на уровне базы данных в наше время страшный моветон и не приветствуется вовсе.

    Но почему-то большинство уверено, что Oracle решает абсолютно все задачи и применим ко всему спектру проблем. По собственной практике, могу сказать, что это не всегда так – Oracle хорош в чем-то, а в чем-то это напрасная трата денег, тут нужны уже совсем другие решения, основанные на других принципах и использующие другие механизмы. Как наглядный пример, могу привести область DWH, аналитическую обработку больших объёмов данных – можно, конечно, купить Oracle Exadata – но соотношение эффективность на объем затраченных денег у него будет минимальным по сравнению с решениями других производителей.

    Маркетинг проникает в умы технических специалистов, а они-то казалось бы должны понимать что к чему, так как их работа и заключается в том, чтобы строить следственно-причинные связи и разбираться в происходящих процессах. Не хочу и не буду говорить, что решение Oracle плохие, так как это неправда. Но сказать про то, что агрессивный маркетинг Oracle делает из их пользователей слепых последователей и фанатов мне, кажется, надо.

    Даже такая компания, как IBM стоит в моих глазах гораздо выше, по причине того, что они тратят значительные средства на R&D. В случае с Oracle можно наблюдать обратную ситуацию — компания преследует только получение прибыли, а никак не качественное улучшение научно-технического уровня существующих решений. Exadata – это пока большой маркетинговый шум, оплачиваемый за счет простых пользователей. Как Вы считаете, может быть, Oracle стоит задуматься о том, чтобы тратить меньше на маркетинг и больше на R&D?

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 116

      +2
      Фабула же!!!
        0
        точно, исправил
        +1
        Но почему-то большинство уверено, что Oracle решает абсолютно все задачи и применим ко всему спектру проблем.
        В последнее время* опять все чаще слышу о том, что для того что бы решить все наши проблемы нам нужен оракл

        *в последнее время мы начали проводить собеседования.
          +2
          Я недавно одному Главному Аналитику, который дни напролет проводит в обнимку с ораклом, предложил повесить уникальный ключ на несколько полей. Его ответ: «Я, конечно, могу объединить все три (или четыре, или больше) значения и создать какое-то новое поле, но что это изменит?» Так и живем…
            +1
            Мне, уже больше чем полгода назад, один консультант (у которого было более 15 лет стажа в разработке) говоритл что все эти монги, редисы и прочие ноускули — это так, проходящее, и что я ну совершенно не понимаю ничего в архитектуре серверных приложений. Это после того, как я ему рассказал, как был устроен наш игровой сервер, и почему именно так. В итоге, вместо перехода на могну, мне надо было пойти к начальству, сказать — а давайте купим сервачек за несколько $$k и к нему оракл на $$$k — и все проблемы будут решены. Он то не то что постгрес, который к тому времени уже немного начинал помирать (утилизейнш диска иногда уже и до сотни доходил, когда народ под вечер начинал к нам ломиться)

            Понравилось другое: после его бреда о том, что оракл может гораздо быстрее выбрать одним запросом данные из 30-40 таблиц где в каждой от 10 и до 80 млн записей… (я уже представляю себе эту выборку в 10к+ строк и 200+ столбцов, большинство из которых забито нуллами) нас поспешили прервать, а после и вовсе отказались от его услуг по консалтингу.
              +2
              Расскажите, пожалуйста, что не так в оракле с уникальными ключами на несколько полей.
              У меня отношение с ораклом весьма потребительское — тонкой оптимизацией не занимаюсь. Есть какие-то не явные проблемы?
                +4
                Дело не в оракле. Вкратце у человека понятие композитного ключа соответствует созданию вычисляемого поля, на которое вешается уникальный ключ.
                  0
                  И на физическом уровне этот человек абсолютно прав.
                  Один раз такое поле точно вычисляется и сохраняется как часть индекса в индексном блоке. Может, он такими категориями мыслил? ) Хотел сэкономить на дисковом пространстве?
                0
                не понял прикола, можете объяснить?
                уже разъяснили, спасибо. В таком случае непонятна фраза «спит в обнимку с ораклом». Ведь чел даже концепты не полистал. ))
              +8
              У нас второй день тормозит exadata… причины хрен найдешь.
              Скорее всего из-за тестирования другого продукта жизнидеятельности oracle — siebel :-D
              Разработка под oracle требует много нарктиков ибо любой хороший продукт с ораклом либо не работает, либо работает хреново.
              У ораклового клиента мало того, что нет инсталера нормального(под *никс), так его даже нет в репах oracle linux — с этого обычно начинается знакомство с oracle :-D а уж если его поставить RAC'ом, то вообще тушите свет.
                +4
                Под Windows нативный клиент не лучше. Если вам нужно настроить 32bit и 64bit билды инсталлера своего продукта первый раз, вас ждет много секаса.
                  0
                  +100, подпишусь. Мудацкое отношение компании к клиентам видно уже на этапе установки софта. А кто устанавливал патчи на оракл? Из хотя бы раз видевших Windows update… Что, так трудно сходить софту на сервер, отдать свой конфиг, автоматически закачать список рекомендуемых обновлений и показать администратору?
                  +2
                  Не понял, чем runInstaller вам не инсталлер?
                  Да, есть свои ньюансы, но в них разбираешься быстро и проблем минимум вдальнейшем.
                    0
                    я говорил об установке Oracle Instance Client из rpm в Oracle Linux(ну или любом другом).
                    А Вы сейчас о чем?
                      +2
                      Я о том, что тем, кто с 1997 года, например, пользуется oracle installer не кажется, что в нем есть что-то ненормальное :)
                      Он универсальный под все платформы — в этом его главный плюс.
                        +2
                        Я, честно говоря, сегодня первый раз про него услышал и сразу из гугла не понял что это.
                        В Oracle linux я первым делом попробывал yum… потом поматерился.
                        Погуглил и попал на www.oracle.com/technetwork/database/features/instant-client/index-097480.html и еще поматерился, когда пришлось региться.
                        Хотел было использовать wget, но пришлось опять материться.
                        Скачал, скопировал на сервер, поставил rpm, начал компилить либу, которой нужен клиент… поматерился.
                        Полез править /etc/profile и добавлять запись /etc/ld.conf.d

                        Если подскажите, как это сделать по другому, я буду Вам вечно благодарен :)
                          0
                          Я предпочитаю полный клиент — там много всякого полезного по жизни. Это четвертый из семи диск в дистрибутиве.
                          Скачивать его можно с сайта oracle.com, но правильнее качать последний патч (с 11-ой версии oracle пачти являются полными дистрибутивами) с support.oracle.com 11.2.0.3
                          Это четвертый из семи диск в дистрибутиве.
                          А далее внимательно изучить приложенный readme на предмет intallation prerequests и сам installation.
                          Можно еще последний Opatch и PSU накатить для верности :)
                            +2
                            Похоже мой путь всё таки проще :)
                            Когда я последний раз пытался зайти в оракловый суппорт(30.10.2012), он сутки не работал :-D
                            image
                            А вот так я после этого пытался обновить SQL Developer
                            image
                    +2
                    >У нас второй день тормозит exadata… причины хрен найдешь.

                    А чего там искать-то? Зайти в какой-нибудь ейный enterprise manager, вкладка performance->top activity и все как на ладони.
                    Сколько активных сессий, по каким классам ожиданий и разбивки глубже. Самые тяжелый запросы и т.п…
                      –1
                      У нас есть целый отдел DBA + поддержка крупного интегратора — пока не справились с проблемой :(
                      0
                      продукта жизнидеятельности oracle — siebel

                      От жизнедеятельности Oracle в продукте Siebel — только интеграции с другими оракловыми продуктами.
                      Сам Siebel к Ораклу никакого отношения не имеет, т.к. родительская контора была поглощена на пике своего развития когда всё уже было разработано.
                        0
                        Ну это было достаточно давно, и к настоящему моменту(8.2) там чувствуется застоявшийся дух Oracle
                      +6
                      Единственное что для меня лично отсутствует в PostgreSQL это запуск единственного SQL запроса на отдельных ядрах процессора или параллельное исполнение одного запроса. Oracle естественно мощнее в этом смысле, но опять же, в балансе между функциональностью и стоимостью (да и простотой администрации и настройки) PostgreSQL выигрывает (по крайней мере в моих системах).
                        0
                        Postgres 9.4 меня жестоко разочаровал непонятными тормозами при выборке нескольких десятков тысяч строк из двухсотмиллионной таблицы по BTree индексу. По одному ключу записи выбираются 35 ms, по тысяче ключей — уже полее получаса. Причём с индексом время получается даже польше, чем при seq scan. В explain plan смотрел — ужасно оргомное время поступа именно к индексу. С какого перепугу — неясно.
                          0
                          Нужно переиндексировать и вообще проверить если индекс заявлен как уникальный, а реально он повторяется и т.д.
                          Советую зайти на #postgresql irc.freenode.net

                            0
                            Спасибо за совет! Конечно, индекс перестраивал… Он неуникальный. Но всё же…
                      • UFO just landed and posted this here
                          +1
                          Teradata никогда не претендовала на этот рынок и разрабатывала свои решения в строгой концепции с DWH. OLTP для них неизведанный мир, нет ни одной Teradata в промышленной эксплуатации(насколько я знаю), использующаяся, как OLTP. Я также не знаю ERP, CRM и подобный решений, использующих Teradata.
                            0
                            По OLTP — правда, никогда не был фокусом Teradata, а вот примеры когда под CRM в качестве СУБД стоит Teradata — есть.
                          0
                          «так как использование бизнес логики на уровне базы данных в наше время страшный моветон и не приветствуется вовсе»

                          А чем объективно плоха бизнес-логика на стороне БД?
                          • UFO just landed and posted this here
                              +3
                              1. Но мы помним, что язык SQL не так универсален в современном мире? И как минимум небольшой вендор-локин у нас в любом случае.
                              В частности различные подсказки для оптимизатора, такие вещи как партиционирование и т. д.
                              В любом случае не получится перенести серьезное приложение без переписывания кода.
                              2. В каком месте неохотно масштабируется, на реальных вещах если можно?
                                +4
                                Ваши слова основываются на реальном опыте? Мне довелось участвовать в разработке одной и той же системы, один вариант которой был реализован на pl/sql, второй — на .net. Так вод логика внутри БД оказалась на порядок быстрее при том, что данных было тоже на порядок больше (на всякий случай уточню: реализовывали биллинговую систему). При этом на привязку к Ораклу было глубоко всем наплевать, ибо переходить ни на что другое даже в мыслях не было, а по масштабированию… база не напрягаясь делала то, на что у дотНета в тестовом прогоне уже не хватало памяти :)
                                  +1
                                  Раскажите роль системы контроля версий, тестов, оценки качества кода и процесса деплоя — вот что будет интересно.
                                  А главное какая была система логирования? Понятно что во время разработки должен быть дебаг режим, а на продуктиве, к примеру, должны быть моментальные оповещения при исключительных ситуациях(например email с данными или смс с угрозой).
                                    +1
                                    Да нормально всё с этим. Автономные транзакции для логгирования, для дебага — внутренние настройки софтины и оракловые контексты сессий, DBMS_PIPE, DBMS_ALERT и, наконец, Advanced Queues для организации очередей оповещения. UTL_HTTP, UTL_SMTP и прочее для организации транспорта оповещения. Много что есть интересного и удобного, если доку читать и не пытаться изобретать велосипеды.
                                      –2
                                      Я знаю что все это есть, знаю как сложно с этим работать, а главное знаю что в любом фреймворке любого нормально ЯП Вам даже доку для таких элементарных вещей читать не пришло — это бы просто было и работало.
                                      Покажите мне mail(или что-то типа того) с трейсом ошибки, который Вы сделали или хотя бы используете и я покажу Вам свои, которые просто сами приходят :)
                                        +2
                                        Не понял, что не так? Если вы знаете, что в Оракле есть механизмы, то к чему тогда вопросы? То, что нужно написать свою реализацию отправки письма, использующую оракловый пакет, а не воспользоваться готовым фреймворком? Ну да, нужно сделать лишнее ручное движение. Зато скорость работы перекрывает все подобные издержки. Что не так с тестированием? Берете и покрываете тест-кейсами все, что захотите. Какая разница? И да, результаты тестирования можно присылать по СМС-ке, только у нас из-за бесплатности используемого механизма была задержка в 7 мин. Повторюсь еще раз: где во главу угла ставится скорость работы, там большинство фреймворков и шаблонов проектирования идут лесом! Никто не будет оценивать красоту вашей архитектуры и легкость реализации, если система не работает (а медленно работающая считается не работающей!).
                                          –2
                                          Не так, что это всё никто не делает из-за геморойности.
                                          Не так, что продукт будет делать как минимум на порядок дольше(Вы же сами всё пишете).
                                          Не так, что будет больше ошибок(ведь Ваш велосипед только Вы тестируете).
                                          Не так, что изменения сложней вносить.
                                          Не так, что нет IDE для этого.
                                          Не так, что не возможно сделать gracefull restart.
                                          Не так, что Вы будете вынуждены вынести сервер в деметализированную зону для общения с партнерами или всё равно писать вокргу БД какой-то софт.
                                          Не так, что после того как Вы из-за предыдущего пункта напишите какой-то софт, Вам придется владеть 2 раза большим кол-вом технологий, т.е. увеличить технологический долг сразу в 2 раза.

                                          главное конечно — vendor lock-in, но это не в тему.
                                            +4
                                            Вы часто встречали серьезные системы, в которых заранее не известна база данных? Простая логика говорит, что стараясь подстроится под всех, вы не сможете воспользоваться плюшками ни одной. Поэтому еще на начале проектирования выбирается конкретная СУБД и дальше пляшут от нее. За 12 лет работы я только однажды участвовал в проекте, где по требованиям нужно было сделать поддержку трех различных БД. Во всех остальных случаях база была известна заранее, что позволяло использовать преимущества именно ее.

                                            Теперь про геморойность. А кто сказал, что создание систем — это легко? Да, нужно руками делать вещи, которые в каких-нибудь фреймворках уже готовы. И не факт, что сделанное самостоятельно будет хуже черного ящика, в работоспособность которого веришь со слов индуса. Конечно, это сложнее и ответственности больше. Ну дык и заплатят за систему, обсчитывающую десятки сущностей в секунду против десятков секунд на одну сущность у индусов, гораздо больше :)

                                            PS. Не думайте, что фреймворки и шаблоны — это панацея от всех бед. К сожалению, многие утрачивают здравый смысл в погоне за «правильностью»…
                                              –1
                                              Да, очень часто. Точнее я видел тока одну большую систему жестко заточенную на БД.
                                              1. Практически все крупные CRM системы работают на разных базах. Это касается и Oracle Siebel CRM.
                                              2. Практически все BI системы поддерживают разные БД
                                              Все остальное — мелочи и\или говнософт, за редким исключением.
                                              Весь банковский или подобный софт строится вокруг CRM.
                                              Могу предположить, что сильно самописные тока игры, биржи и web гиганты типа google.

                                              А заплатят больше за то, что раньше сделают и будут продавать. Siebel откровенное говно, причем крайне медленное(я бы даже сказал фантастически медленное), но не думаю что бывает софт дороже.
                                                +2
                                                Я понял, мы рассматриваем разные типы продуктов. Вы говорите о коробочных вариантах, неких универсальных решениях, готовых «работать» где и с чем угодно, а я имею ввиду штучные системы под конкретных заказчиков. В первом случае интеграторы пытаются натянуть бизнес клиента на имеющийся глобус, во втором — изобретается велосипед под конкретные нужды бизнеса. Так вот в вариантах с «говнософтом», как вы изволили выразиться, тип БД определяется заранее.
                                    +1
                                    О чем и речь, такое ощущение, что господа не имеют опыта работы.
                                    Дело не только в переносимости, когда речь заходит о производительности, разница которого измеряется порядками.
                                      –2
                                      Первым делом нужна надежность и отлаженный цикл разработки.
                                      Только потом можно начинать думать о скорости, тем более что сервера стоят копейки(если на них нет стикера Oracle).
                                        0
                                        Это у вас не хватает опыта серьезных проектов и вы начитавшись умных книжек говорите про то, как важно
                                        соблюдать цикл разработки, и какие вы тут все крутые программисты.
                                        Как у вас красиво деплоится и генерируется код.
                                        В реальной жизни, когда вы столкнетесь с серьезным проектом, когда несколько десятков терабайт текстовой информации нужны здесь и сейчас, все меняется.
                                        И количества программистов, а главное качества, начинает резко не хватать.

                                        А пока да, производительность на втором месте.
                                          0
                                          Когда от правильности и надежности Вашего кода зависит подсчет бабла, мыслить приходится по другому :)

                                          Вот это классно, когда из-за какой-то мелкой логической ошибки, которую отловил бы unit test в одну строчку, ты
                                          портишь «десятки террабайт», а потом сидишь в даунтайме, пока бэкап накатится :-D

                                          А что не так с десятками террабайт? Проблема купить еще половинку экзадаты?

                                          То, что многие жлобятся на лишних программистов — мягко говоря, проблемы индейцев. (с) EugeneO
                                            0
                                            «А что не так с десятками террабайт? Проблема купить еще половинку экзадаты?»

                                            Вы прикалываетесь?
                                            Здесь речь идет в контексте полного ухода от оракла и/или оракл не панацея.

                                            Покупка Экзадаты это конечно не vendor lock-in и прочее, прочее говно с ним связанное.
                                              0
                                              Проблема купить Terradata? :)
                                              Ну или для вариант для бедных — один из форков postgres может работать прикидываясь ораклом(для переходного периода) и стоять RAC'ом.
                                              В контексте полного ухода от оракла есть куча прекрасных технологий — hadoop, всякие приватные и не очень обалка и т.д.
                                                +1
                                                Вы со своими hadoop'ами, знаете куда пойдете, если предложите данное решение банкам например?

                                                А Terradata, это тот же самый vendor lock-in, а так же куча других минусов с ним связанных.

                                                Но суть в том, что все что вы описали и Oracle DB имеют радикально разные предназначения.
                                                  0
                                                  Для меня его предназначение — Хранение.
                                                  Есть разные способы хранения. У всех есть свои плюсы, минусы и предназначения.
                                                  На выбор оракла банками, никак не влияют его возможности.
                                                  Но есть редкие руководители банков, которые держат у себя настоящих IT'ишников в руководстве
                                                  Куда я должен пойти из банка с hadoop?
                                                  www.slideshare.net/m_hepburn/apache-hadoop-bigdatainbanking
                                                  www.forbes.com/sites/tomgroenfeldt/2012/05/30/morgan-stanley-takes-on-big-data-with-hadoop/
                                                  Еще погуглить?

                                                  P.S. hadoop'ом не пользовался. так к слову сказал.
                                                  +1
                                                  hadoop как замена Oracle? Вы это серьёзно?
                                                  Нет, я не про то, что hadoop плох. Просто это немного другое. Ну, всё равно что вилка взамен картошки :)
                                                    0
                                                    Сюрприз, оракл уже некоторое время Hadoop покупателям толкает (сейчас это дистрибутив cloudera).

                                                    Наглядным примером (по крайней мере для меня) оказался Oracle Big Data Appliance, который, как оказалось, является просто Apache Hadoop с блекджеком и прочими плюшками от Oracle — каков ценник на эти самые «плюшки» можно лишь догадываться.

                                                    www.insight-it.ru/ru/life/google-developer-day-i-oracle-day-2011/
                                              0
                                              А что вы предлагаете как более надежное?
                                              +1
                                              Вообще, когда разработчик заводит разговоры о производительности в ущерб надежности и при этом приводит в качестве аргументов наезды на чей-то опыт работы — у меня возникают сомнения в том, что этот разработчик когда-либо работал более чем в одном или паре долголетних легаси-энтерпрайзных проектов и интересуется чем-либо за пределами своего маленького мирка.

                                              Наблюдал неоднократно конкретно у ораклистов.

                                              Вот конкретно прямо сейчас наблюдаю охрененные проблемы с масштабируемостью и поддержанием качества в большом старом интернет-проекте сделанном исторически на хранимках.
                                                0
                                                Почему в ущерб надежности?

                                                Никто не говорил, что PL/SQL менее надежен.
                                                Просто применяются немного иные алгоритмы работы.
                                                Можно например иметь тестовый сервер и прочие решения.

                                                Суть в том, что это не проблемы если их можно решить.

                                                Когда приложение не отвечает на запросы,
                                                тут дисциплиной разработчиков например ничего не добьешься.
                                                И вот это действительно проблема когда не хватает производительности.
                                                  +1
                                                  На PL/SQL крайне гемморойно писать автоматизированные тесты и субъективно он сам по себе (как и другие диалекты SQL) чересчур толерантен к ошибкам разработчика (там где c# или java упадут на этапе сборки, хранимка радостно уйдет в базу данных, где ее уже могут продолбать тестировщики).

                                                  Суть в том, что проблемы можно решать многими способами и решать их ДЕШЕВО выгоднее, чем ДОРОГО. А дешевле всего они решаются тогда, когда исключен человеческий фактор.

                                                  Если есть проблема с производительностью выборки или обработки данных в каком-нибудь конкретном месте я первый скажу, что в этом месте нужно написать хранимку. Но не надо писать на них ВСЕ, как это было принято во времена двухзвенных систем, и строить архитектуру приложения вокруг хранимок.

                                                  Проблемы с масштабируемостью начинаются тогда, когда начинаются попытки разделить на шарды или федерацию старую базу данных спроектированную под вертикальное масштабирование и с большим количеством выборок с джойнами. А такое сейчас встречается очень часто.
                                                    0
                                                    Нет, ну про ВСЕ и речи нет.
                                                    И не говорю, что PL/SQL легок и дешев.

                                                    Согласитесь и вы, есть задачи, в которых его использование очень оправдано.
                                                      +2
                                                      Безусловно, есть ситуации когда использование хранимок оправдано и их плюсы перевешивают возникающие проблемы.

                                                      Я говорю о ситуациях и проектах, где хранимки используются для бизнес-логики повсеместно и в итоге создают проблемы, а не решают их.
                                                  0
                                                  Вот вы сейчас написали, и я улыбнулся. Как же я мог забыть, что наблюдаю сейчас ту же самую картину :)

                                                  К слову, мы сейчас этот проект переписываем. И уже СУБД независимо.
                                                    0
                                                    У нас будет переделываться на SOA, где каждый сервис будет иметь собственное изолированное хранилище данных (выбираемое под конкретные задачи конкретного сервиса) и масштабироваться независимо от других.
                                                0
                                                Мне довелось участвовать в разработке одной и той же системы, один вариант которой был реализован на pl/sql, второй — на .net.

                                                Можно по подробнее, это как?
                                                Одна система полностью на pl/sql, другая полностью на .net?

                                                Или перенесли 1 процедуру с pl/sql на .net и показали производительностью pl/sql?
                                                Если последнее, тогда тут я могу вас огорчить, т.к. структура системы будет иначе. А соответственно и способ обращения данным, эффективность кеширования и т.д. будет другой.
                                                  0
                                                  Торопился уложиться в 3 минуты редактирования, напортачил :)

                                                  Если последнее, тогда тут я могу вас огорчить. Структура системы (при разработке без использования для бизнес-логики в БД)будет иной, а соответственно и способ обращения данным, эффективность кеширования будут иметь совершенно другое значение в скорости работы и реакции приложения.*
                                                    +2
                                                    Частично.
                                                    Некоторые вызовы делаются целиком на стороне БД, и могут вызываться откуда угодно.
                                                    Есть еще такая штука, как целостность данных в данном контексте, которая на стороне БД имеет больше шансов на успех.
                                                    Всякие банки и тот же билинг критичны к ним.
                                                      0
                                                      Разрабатывать большую систему, где целостность данных проверяется на стороне БД, не в идеальных системах крайне трудоёмко. Опять же все утыкается либо в универсальность либо в количесво специалистов. И если целостность контролировать на уровне БД и привлекать дополнительных сепециалистов, нужно так же еще и расширять штат управленцев, которые будут руководить потоком задач от разработчиков на ЯП(языке программирования) к спец PL/SQL и обратно.
                                                      + Нужны дополнительные ресурсы на документирование разделения логики, т.к. код размазан по БД и системе.

                                                      К тому же, как правило, целостность на столько сложна, что реализовать её лишь в pl/sql на стороне БД невозможно, т.к. у неё не хватает данных.
                                                    0
                                                    >> Можно по подробнее, это как?

                                                    Первый вариант — на pl/sql, [почти] двухзвенная архитектура, где клиент знает только названия и параметры хр. процедур, реализующих бизнес-логику, а внутри процедур уже идут выборки, журналирования, проверки прав доступа и т.п.

                                                    Второй вариант — на .net, трехзвенная архитектура, когда всю логику реализует сервер приложений, написанный на C#. В этом варианте от БД требуется только insert/update/delete.
                                                    0
                                                    поддерживаю. У нас тоже парочка биллинговых систем с логикой в оракле. Там даже ООП удалось использовать в некотором виде — и наследование, в том числе. Работает хорошо. Хотя есть и минусы у этого решения: нельзя разделить по серверам хранение данных и вычисления. но далеко не всегда это, собственно, и нужно.

                                                  0
                                                  Тем, что привязывает вас к определенной БД. Языки программирования имеют меньше привязки, даже .NET. Также меньше тулов? как source control или continuous integration. Можно закончить, что вы будете обмениваться DUMP базы данных, а не исходным кодом…
                                                  Плюс, с логикой в БД должен разбираться DBA, а с application логикой, программист.
                                                    +2
                                                    «Плюс, с логикой в БД должен разбираться DBA, а с application логикой, программист.»

                                                    Не понял, PL/SQL по вашему имеет отношение к DBA?
                                                    Я такого не видел.
                                                      +1
                                                      и, в некоторых случаях, полностью отвязывает от платформы клиентских приложений или решает многие проблемы с написанием кросс-платформенных клиентов.

                                                      И да, с логикой в БД должен разбираться PL/SQL-программист, это не задача DBA.
                                                      +1
                                                      Тем что она, в общем случае, повышает сложность разработки. Т.к. нужно знать что крутится на стороне БД, а что на стороне кода. И что бы это не произошло, нужно четко выделить уровни абстракции заранее. А это, в свою очередь, не очень то и тривиальная задача. Т.к. даже проектирование идет поэтапно.
                                                      Плюс, сейчас при проектировании пытаются заложиться на абстрагировании от БД, Так проектировать проще и лучше для бизнеса с точки зрения, предоставления выбора альтернатив заказчику.
                                                      К тому же, нужно заложиться на то, что либо ваши специалисты должны уметь писать код на языке программирования и на языке БД, либо всегда иметь отдельных специалистов(и несколько, на случай болезни 1). Что, согласитесь проблематично в 1 случае, и не выгодно во втором.

                                                        –1
                                                        +1 не видел DBA умеющих программировать, хотя наших даже заставляли делать soap запросы из бд… которые в итоге писали программисты, слава богу эти процедуры пока не используются :-D
                                                          +1
                                                          dba может и не должен много программировать, но разбираться в чужом коде, не говоря про владении в совершенстве написанием запросов обязан.
                                                          Иначе какой может быть performance tuning?
                                                            0
                                                            DBA не имеет отношения к программированию и не должен по определению.
                                                            –1
                                                            Утверждения «не умеет писать код на языке БД» и «не понимает как БД работает» — утверждения практически идентичные — реально одно без другого немыслимо. Писать СУБД должны люди, которые понимают, что такое БД. Иначе настроят чугуниевых велосипедов, которые не ездят.
                                                              0
                                                              Писать СУБД должны люди, которые понимают, что такое БД.

                                                              Это вы сейчас вообще к чему?
                                                              Кто пишет СУБД?
                                                              При чём тут написание СУБД?

                                                              Утверждения «не умеет писать код на языке БД» и «не понимает как БД работает» — утверждения практически идентичные

                                                              Я знаю язык запросов. Я не умею писать хранимые процедуры.
                                                              Для меня, как разработчика некого продукта, БД это сервис для хранения данных. Что значит «не понимает как БД работает» — остается очень абстрактной фразой. Уровень понимания работы БД не детерминирован вами.
                                                                0
                                                                СУБД — да, неудачная коллизия с устоявшимся термином, хотя подразумевается, разработка сложной системы управляющей базой данных :-)

                                                                > Я знаю язык запросов. Я не умею писать хранимые процедуры.
                                                                Выходит, вы не знаете язык запросов.

                                                                Точно так же как то, что я когда прочитал Страуструпа, и могу матрицы на C++ перемножить, не говорит, что я знаю C++
                                                                  0
                                                                  Выходит, вы не знаете язык запросов.

                                                                  Я знаю язык запросов для использования БД как систему сохранения и получения данных.
                                                                  Что бы вам было попонятнее, что я вам говорю, задайтесь вопросом, что такое «понимать как работает БД».
                                                                  С точки зрения разработчика СУБД, можного говорить, что вы не понимаете как работает БД. С точки зрения прикладного программиста, вы знаете. Определитесь с определением «понимать».
                                                                    0
                                                                    > Я знаю язык запросов. Я не умею писать хранимые процедуры.
                                                                    Выходит, вы не знаете язык запросов.


                                                                    Давайте всё-таки определимся со слоями в современных СУБД. Очень-очень грубо и непростительно неточно, потому что быстро и коротко. Ну и поскольку топик про оракл, всё будет в его терминах. Поехали.

                                                                    Есть строки данных, которые хранятся в блоках, которые объединяются в экстенты, которые принадлежат сегментам. Есть блокировки для защиты строк и защёлки для защиты структур памяти. Давайте вынесем это в нижний, «физический» слой СУБД.

                                                                    Для управления данными необходим некий интерфейс к ним. В РСУБД этот интерфейс сейчас более-менее стандартизирован и называется Structured Query Language. Движок SQL. Давайте в нашей грубой модели отнесём к его обязанностям описание сущностей в привычных человеку терминах, управление логической целостностью данных и придумыванием, как быстрее всего их вытащить с нижнего слоя.

                                                                    В 80-ых это был предел желаний и все отлично обходились вариантом «СУБД для хранения и управления данными, а для логики у нас есть куча удобных и прикольных языков». Но аппетиты быстро растут, а идеалы часто меняются, поэтому появилось понимание, что часть логики было бы безумно здорово перенести напрямую в СУБД, чтобы не гонять туда-сюда сырые данные между сервером БД и приложением. Так появился движок PL/SQL. Ничего не напоминает? Рос он рос и дорос до уровня полноценного сервера приложений с великим множеством возможностей и плюшек.

                                                                    Мораль сей басни: движок SQL и движок PL/SQL — это две совершенно разные вещи. Внешне их постарались причесать под одни и те же стандарты, но внутренне они различаются очень сильно. Множество примеров внутренних (и, обычно, недокументированных) различий можно найти в топиках на sql.ru.

                                                                    Ну и, наконец, слова SowingSadness`а «знаю язык запросов, но не умею писать хранимые процедуры», говорят лишь о том, что он прекрасно понимает различие между SQL и PL/SQL.
                                                              0
                                                              Вы пробывали сделать Continuous Integration для логики в БД?
                                                              Если попробуете, до думаю у Вас всё время уйдет на настройку CI и продумывание его архетектуры :-D
                                                              А без этого делать что-то серьезное лучше даже не начинать.
                                                                0
                                                                Вы рассматриваете только одну не самую важную деталь вопроса.
                                                                  0
                                                                  Добавьте сюда деплой, версионирование и хранение исходников.
                                                                    0
                                                                    В чем проблема?
                                                                    Конкретно, в чем проблема версионирования и хранения исходников PL/SQL или какого-нибудь другого хранимого кода?
                                                                      0
                                                                      А вы знаете как их нормально хранить — кроме как полный дамп базы со всем хламом?
                                                                      Как накатывать изменения и откатывать?
                                                                      Как деплоить их не делая иногда ALTER DATABASE KILL SESSION?

                                                                      Если вы знаете здесь best practices поделитесь — мне лично очень интересно.
                                                                        +4
                                                                        > А вы знаете как их нормально хранить — кроме как полный дамп базы со всем хламом?

                                                                        В данном случае просто нужна дисциплина. Никогда не редактировать и не отлаживать процедуры «по месту», прямо в базе. Строго — скрипт создания процедурного объекта редактируется во внешнем файле (и сохраняется в системе управления версиями), только после этого он исполняется в СУБД.
                                                                          +1
                                                                          Сейчас специально посчитал сколько у свеже поставленного Oracle Siebel CRM таблиц в схеме… 4728.
                                                                          Внимание вопрос — на сколько надо быть дисциплинированным, если пишешь софт вокруч чего-то подобного :-D
                                                                          Вроде как Сбер внедряет Siebel — ад для pl\sql'щиков
                                                                          0
                                                                          Мы говорим про хранимую логику — зачем полный дамп? Если речь идет не об изменении структур данных и самих данных, которые безразлично от местонахождения логики придется менять/откатывать, то местонахождение логики в базе практически ничем не отличается от промежуточных слоев. pl/sql — это тоже клиент.
                                                                          0
                                                                          Ну попробуйте хотя бы описать как бы Вы всё это реализовали.
                                                                          Вот есть вариант geekswithblogs.net/SQLDev/archive/2012/04/24/database-continuous-integration-step-by-step.aspx
                                                                          На мой взгляд он очень полный и жутко геморойный, по сравнению любым нормальным ЯП.
                                                                          0
                                                                          Это всё и есть CI
                                                                            0
                                                                            CI — это только автоматизированная сборка. Все вместе — continious delivery
                                                                              0
                                                                              Paul M. Duvall, Steve Matyas, Andrew Glover с Вами не согласны :)
                                                                              www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380
                                                                              Хотя я уже встречал такое понятие. CI мне ближе, потому что все сервера CI обязательно указывают в списке фич — деплой.
                                                                              т.е. для меня CI
                                                                              — репозиторий
                                                                              — тесты
                                                                              — оценка качества кода
                                                                              — сборка
                                                                              — выкатка
                                                                              — различные «тормозисторы» сборки и выкатки
                                                                                0
                                                                                Ну как бы во-первых в слове integration есть только «интеграция», а во-вторых википедия и Мартин Фаулер с тусовкой (http://martinfowler.com/delivery.html) не согласны с вашей бригадой ;)))
                                                                          0
                                                                          Я спросил про то, с чего надо начать при разработке. Это не самая главная и не самая важная — это первая деталь.
                                                                          0
                                                                          Почитайте про Edition-Based Redefinition, почитайте старые проверенные простые методы. Все легко и просто. Вообще постарайтесь меньше делать громких заявлений, не имея знаний и опыта, т.к. со стороны это выглядит крайне ужасно.
                                                                            0
                                                                            Всегда есть люди, которые почему-то считают себя круче любого незнакомого им человека.
                                                                            Наверно Вы Линус Торвальдс, ну или Балмер на худой конец :-D
                                                                          –2
                                                                          «А чем объективно плоха бизнес-логика на стороне БД?»

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

                                                                          Во вторых, строго говоря, в функции СУБД не входит выполнение каких-либо команд, не относящихся к извлечению данных. А тут все наоборот — в одной СУБД наворочено черте что — AQ, MGW, Streams, работа с файлами, работа с почтой, Scheduler, пакеты со сложной логикой. Через некоторое время, все это становится настолько запутанным и сложным, что вопрос — как это поддерживать дальше становится критическим. Где вы получаете данные, а где просто отправляете почту? Необходимо больше квалифицированных специалистов, для поддержки всего этого нужна большая команда — нужны PL/SQL разработчики(желательно сертифицированные), архитекторы, куча DBA, тестеры на ту часть, на эту часть. Все это начинает работать плохо, понятие thread незнакомо oracle. Пользуетесь DBMS_JOB? В 11g это теперь включено в DBMS_SCHEDULER — надо переделывать. При взгляде на счета за поддержку такой системы владельцы бизнеса хватаются за сердце — Ларри Эллисон покупает еще остров. Хотите переехать на другую СУБД — даже не мечтайте.

                                                                          Хотелось бы классифицировать тему про бизнес-логику в СУБД по ЯП(скорей даже по фреймворкам):

                                                                          1) PL/SQL. Oracle не только реализовал свой полноценный язык программирования(хотя официально это считается процедурным расширением SQL — странный подход, по моему мнению), но и построил вокруг него свой блэкджек с аттракционами. Oracle Forms, Oracle Reports, Oracle Applications — если вы используете все это, то реализация логики на стороне БД вас неизбежно настигнет — тут никуда не денешься. Если проект достаточно масштабный, то через некоторое время понимать, что там происходит, будут только старожилы.

                                                                          2) .NET, Java. Тут несколько сложнее, вспоминаем про очистку мусора — использовать большие массивы памяти для хранения данных довольно накладно в плане операционных расходов на очистку мусора. Если использовать их достаточно интенсивно и в больших объемах, то сталкиваемся с STW. Поэтому малодушные переносят часть логики в СУБД, думая, что избавились от головной боли, а заодно и повысили быстродействие — Java-то летает. Через некоторое время возникают проблемы — как масштабировать непонятно, слово «рефакторинг» вызывает истерический смех, PL/SQL вызывает лютую ненависть. Другие нанимают высококвалифицированного DBA, который бьет по рукам всех, кто вызывает неэффективные запросы к БД, используется несколько серверов или экземпляров приложений, изучают ORM(потому как изобретать велосипед незачем) — тут будущее выглядит более радужно — с масштабированием понятно, растем вширь, не забывая про балансировку. Отважные кидаются на распределенные кэши, coherence, off heap и т.п. — что тоже выход.

                                                                          3) Python, Perl, PHP — это ж скриптовые языки!!! Причем тут бизнес-логика?

                                                                          По остальным ЯП комментарии приветствуются.

                                                                          vendor lock-in — в принципе, не так и страшно, если вендор хороший.

                                                                          Реализация бизнес-логики на уровне СУБД страшный моветон сегодня именно потому, что к сегодняшнему моменту мы имеем кучу систем, которые непонятно, как дальше поддерживать и как дальше масштабировать. Да, они выполняют свои функции в каких-то пределах, а что делать дальше? Не проще ли проектировать такие системы, которые можно поддерживать за разумные деньги и время? Или важнее выйти на рынок раньше всех, а потом думать, как же допилировать её дальше?
                                                                            +1
                                                                            >Пользуетесь DBMS_JOB? В 11g это теперь включено в DBMS_SCHEDULER — надо переделывать.

                                                                            Это не так, ничего переделывать не нужно — все что сделано на dbms_job будет работать в 11g без проблем :)

                                                                            В целом с Вами согласен. Хотя, мне кажется, что простота поддержка больше зависит от качества менеджмента проекта, изначально — в первую очередь правильно разработанной реляционной модели БД и грамотно причесанных бизнес-процессов, качества документирования и т.п., а способы реализации в БД или нет могут влиять больше на то, где у нас будут узкие места в плане производительности, т.е надо выбирать исходя, что мы создаем — биллинг мобильного оператора (склоняюсь к БД) или, например, facebook (тут как раз надо все выносить).

                                                                            Как говорят — если автоматизировать бардак, то получится автоматизированный бардак и ничего более :)
                                                                          +3
                                                                          Спасибо, очень классно написано! Повеселили от души! :)

                                                                          Но, очень странное суждение про применение ExaData для DWH/OLTP

                                                                          Я как раз считал, что ExaData идеальна для DWH так как:
                                                                          1. умеет все классно параллелить
                                                                          2. пропихивает условия из where на уровень «дискового массива», что в результате рвет на грелки все остальные решения, где надо через оптику или т.п прокачать терабайты данных между сервером и массивом.

                                                                          А для OLTP, все что содержит в себе RAC при условии не заточенности приложений — один сплошной гемор — меж-инстансные блокировки и т.п. Это ужас-ужас…
                                                                            0
                                                                            А у нас на ExaData OLTP :-D
                                                                            А всё почему? Потому что продажники Oracle — боги и по совместительству главный актив компании. :)
                                                                              +1
                                                                              Бывает…
                                                                              Все познается в сравнении. Не факт, что на другом продукте было бы лучше…
                                                                                0
                                                                                Озвучьте уже свою компанию…
                                                                                0
                                                                                Exadata хороша для DWH, скажем так, относительно небольших размеров. У нее есть определенные сложности с масштабированием, хотя они попытались решить это превентивно с помощью InfiniBand.
                                                                                Есть неплохой документ от Teradata, описывающий основные недостатки Exadata. Ссылка

                                                                                По мне, основной недостаток — это не MPP система, соответственно, масштабируется плохо. А так, она вполне подходит для среднего класса DWH, если не обращать внимания на её эффективность за такие деньги.
                                                                                  0
                                                                                  Ну, статья от конкурентов вряд ли может претендовать на полную объективность :)

                                                                                  С другой стороны меня только радует, что у oracle по еще есть серьезные конкуренты и хотелось бы, чтобы их было больше. Так как по мне качетсво самой oracle rdbms в плане надежности с тех пор, как я им занимаюсь (1998) изрядно падает.
                                                                                  БД уже напоминает анекдот про самолет с бассейном и прочим, который теперь еще и попытается взлететь :)
                                                                                    0
                                                                                    Видел DWH на Oracle (даже не Exadata) и на Teradata. Различие между ними только одно — Oracle работает.
                                                                                    Справедливости ради, GreenPlum и MS Parallel DWH — тоже работают, и по соотношению стоимость/эффективность вполне возможно, не хуже. Но Терадата — это аццкий ад :(
                                                                                  +1
                                                                                  Слог шикарный…
                                                                                    0
                                                                                    Если вкратце, то полный цикла разработки — это все круги Ада.
                                                                                    0
                                                                                    За что же вы так с лисой? :)
                                                                                      0
                                                                                      На самом деле, у меня самые теплые чувства к FoxPro. На первой серьезной работе использовалась связка VFP + SQL Server. Я тогда буквально влюбился в VFP. До последнего надеялся, что Microsoft одумается и продолжит развитие FoxPro. Но, к сожалению, они закончили поддержку на VFP 9. Жаль…
                                                                                      0
                                                                                      Спасибо за отличную статью. Как жрец ДБА, посмеялся от души. А Оракл… Уже скоро будет 12c, а долговременное хранение ASH data нет, только 10% в авр. Я готов сотни гигабайт под ASH снэпы отдавать, но хоть убейся.
                                                                                        +1
                                                                                        А нафига?
                                                                                          0
                                                                                          Потому что у нас на проде ASH смывается примерно за час-полтора. Не всегда этого времени хватает, чтобы до конца решить проблему производительности. Иногда, если жалоба пришла чуть позже, из AWR просто невозможно уже вытащить нужные данные. Звучит, конечно, довольно наивно, но я не раз сталкивался с ситуациями, когда жалел об отсутствии выгрузки эша на диск 1:1, а не 1:10.
                                                                                            0
                                                                                            Хм… а если увеличить частоту снятия snapshots? У меня стоит 15 минут, вместо дефолтных 30-ти.

                                                                                            Посмотрел ash на своем проде — хранится последние 70 минут :(
                                                                                              0
                                                                                              В ASH снимаются снэпы со всех сессий каждую секунду (поэтому стоит иметь в виду, что даже в ASH некоторые сессии не успеют попасть), а в АВР уходит 10% сэмплов Эша каждые Н минут. У нас 60. ASH же чистится не по времени, а по наполненности, насколько я понял, потому что на тихих непродах, поросших мхом, можно и за вчера остатки данных найти :)

                                                                                              Причём, в данный момент я борюсь с багом (которому нет фикса, привет, Оракл), из-за которого WRH$_ACTIVE_SESSION_HISTORY не сплитается и не пурджится. С февраля 2012 она выросла лишь до 14ГБ примерно. Это та таблица, к которой обращаешься через dba_hist_active_sess_history. Соответственно, если бы можно было хранить эш 1:1, она была бы 140ГБ. Почти за год! На нагруженном продакшне под EBS+SOA+OBIEE+whatnot. Т.е. хранить неделю ASH 1:1, по-моему, не проблема.
                                                                                                +1
                                                                                                Если Вы brave enough и готовы оказаться буратиной для oracle support и, если есть тестовая системка, на которой можно проиграть хорошую нагрузку, то можете попробовать поменять параметр
                                                                                                _ash_disk_filter_ratio с дефолтного 10 на 1-ку :)

                                                                                                Испугали Вы меня этим багом, полез смотреть — все ок, партиции сплитятся каждые четыре дня, каждая объемом порядка 2Гб, хранятся за последние 3 месяца.
                                                                                                У меня 11.2.0.3.2 HP-UX IA64 + еще с десяток one-offs.
                                                                                                  0
                                                                                                  Спасибо, кстати, надо бы попробовать на тестовом трупике дома :)

                                                                                                  11.2.0.2.5 Oracle Linux 5 + uek. Заметили баг, когда аудит базы проводили. Ещё и WRI$_OPTSTAT_HISTHEAD_HISTORY не пурджится. А мануал пурдж бежит по 48 часов на неделю статистики :(

                                                                                                  Причём, что самое интересное, сплиттинг через alter session set "_swrf_test_action" = 72; срабатывает. Даже пурдж срабатывает (я руками сделал сплит, через неделю ещё сплит, вот на днях ушла вторая партиция. Оригинальная огромная партиция так и осталась висеть). Саппорт разводит руками. Есть, вроде бы, патч, но он требует перевода базы в апгрейд, чего бы не хотелось, я не продавлю наверх. Наверное, в ежевоскресный мэйнтенанс добавится ещё один шаг. Эх, ладно, пожаловался на жизнь :)
                                                                                                    0
                                                                                                    Я бы рекомендовал, конечно, перейти 11.2.0.3 + последний PSU. Скоро выйдет 11.2.0.4 (см note 742060.1) и oracle перестанет патчить 11.2.0.2…
                                                                                              0
                                                                                              Кстати, в дополнение к тому, что верно сказал zhekappp, еще могу посоветовать скрипты Танела Подера(snapper, latchprofx и тд). А вообще(не знаю, конечно, какие проблемы решаете вы) серьезные проблемы производительности обычно либо замечаются и решаются сразу, либо легко видны в awr(или еще где-нибудь, в зависимости от характера проблемы), либо легко повторяются. У нас хранение awr две недели — если за этот срок не сообщили о проблеме, значит это и не проблема…

                                                                                        Only users with full accounts can post comments. Log in, please.