Comments 116
Фабула же!!!
Но почему-то большинство уверено, что Oracle решает абсолютно все задачи и применим ко всему спектру проблем.
В последнее время* опять все чаще слышу о том, что для того что бы решить все наши проблемы нам нужен оракл
*в последнее время мы начали проводить собеседования.
В последнее время* опять все чаще слышу о том, что для того что бы решить все наши проблемы нам нужен оракл
*в последнее время мы начали проводить собеседования.
Я недавно одному Главному Аналитику, который дни напролет проводит в обнимку с ораклом, предложил повесить уникальный ключ на несколько полей. Его ответ: «Я, конечно, могу объединить все три (или четыре, или больше) значения и создать какое-то новое поле, но что это изменит?» Так и живем…
Мне, уже больше чем полгода назад, один консультант (у которого было более 15 лет стажа в разработке) говоритл что все эти монги, редисы и прочие ноускули — это так, проходящее, и что я ну совершенно не понимаю ничего в архитектуре серверных приложений. Это после того, как я ему рассказал, как был устроен наш игровой сервер, и почему именно так. В итоге, вместо перехода на могну, мне надо было пойти к начальству, сказать — а давайте купим сервачек за несколько $$k и к нему оракл на $$$k — и все проблемы будут решены. Он то не то что постгрес, который к тому времени уже немного начинал помирать (утилизейнш диска иногда уже и до сотни доходил, когда народ под вечер начинал к нам ломиться)
Понравилось другое: после его бреда о том, что оракл может гораздо быстрее выбрать одним запросом данные из 30-40 таблиц где в каждой от 10 и до 80 млн записей… (я уже представляю себе эту выборку в 10к+ строк и 200+ столбцов, большинство из которых забито нуллами) нас поспешили прервать, а после и вовсе отказались от его услуг по консалтингу.
Понравилось другое: после его бреда о том, что оракл может гораздо быстрее выбрать одним запросом данные из 30-40 таблиц где в каждой от 10 и до 80 млн записей… (я уже представляю себе эту выборку в 10к+ строк и 200+ столбцов, большинство из которых забито нуллами) нас поспешили прервать, а после и вовсе отказались от его услуг по консалтингу.
Расскажите, пожалуйста, что не так в оракле с уникальными ключами на несколько полей.
У меня отношение с ораклом весьма потребительское — тонкой оптимизацией не занимаюсь. Есть какие-то не явные проблемы?
У меня отношение с ораклом весьма потребительское — тонкой оптимизацией не занимаюсь. Есть какие-то не явные проблемы?
уже разъяснили, спасибо. В таком случае непонятна фраза «спит в обнимку с ораклом». Ведь чел даже концепты не полистал. ))
У нас второй день тормозит exadata… причины хрен найдешь.
Скорее всего из-за тестирования другого продукта жизнидеятельности oracle — siebel :-D
Разработка под oracle требует много нарктиков ибо любой хороший продукт с ораклом либо не работает, либо работает хреново.
У ораклового клиента мало того, что нет инсталера нормального(под *никс), так его даже нет в репах oracle linux — с этого обычно начинается знакомство с oracle :-D а уж если его поставить RAC'ом, то вообще тушите свет.
Скорее всего из-за тестирования другого продукта жизнидеятельности oracle — siebel :-D
Разработка под oracle требует много нарктиков ибо любой хороший продукт с ораклом либо не работает, либо работает хреново.
У ораклового клиента мало того, что нет инсталера нормального(под *никс), так его даже нет в репах oracle linux — с этого обычно начинается знакомство с oracle :-D а уж если его поставить RAC'ом, то вообще тушите свет.
Под Windows нативный клиент не лучше. Если вам нужно настроить 32bit и 64bit билды инсталлера своего продукта первый раз, вас ждет много секаса.
+100, подпишусь. Мудацкое отношение компании к клиентам видно уже на этапе установки софта. А кто устанавливал патчи на оракл? Из хотя бы раз видевших Windows update… Что, так трудно сходить софту на сервер, отдать свой конфиг, автоматически закачать список рекомендуемых обновлений и показать администратору?
Не понял, чем runInstaller вам не инсталлер?
Да, есть свои ньюансы, но в них разбираешься быстро и проблем минимум вдальнейшем.
Да, есть свои ньюансы, но в них разбираешься быстро и проблем минимум вдальнейшем.
я говорил об установке Oracle Instance Client из rpm в Oracle Linux(ну или любом другом).
А Вы сейчас о чем?
А Вы сейчас о чем?
Я о том, что тем, кто с 1997 года, например, пользуется oracle installer не кажется, что в нем есть что-то ненормальное :)
Он универсальный под все платформы — в этом его главный плюс.
Он универсальный под все платформы — в этом его главный плюс.
Я, честно говоря, сегодня первый раз про него услышал и сразу из гугла не понял что это.
В Oracle linux я первым делом попробывал yum… потом поматерился.
Погуглил и попал на www.oracle.com/technetwork/database/features/instant-client/index-097480.html и еще поматерился, когда пришлось региться.
Хотел было использовать wget, но пришлось опять материться.
Скачал, скопировал на сервер, поставил rpm, начал компилить либу, которой нужен клиент… поматерился.
Полез править /etc/profile и добавлять запись /etc/ld.conf.d
Если подскажите, как это сделать по другому, я буду Вам вечно благодарен :)
В Oracle linux я первым делом попробывал yum… потом поматерился.
Погуглил и попал на www.oracle.com/technetwork/database/features/instant-client/index-097480.html и еще поматерился, когда пришлось региться.
Хотел было использовать wget, но пришлось опять материться.
Скачал, скопировал на сервер, поставил rpm, начал компилить либу, которой нужен клиент… поматерился.
Полез править /etc/profile и добавлять запись /etc/ld.conf.d
Если подскажите, как это сделать по другому, я буду Вам вечно благодарен :)
Я предпочитаю полный клиент — там много всякого полезного по жизни. Это четвертый из семи диск в дистрибутиве.
Скачивать его можно с сайта oracle.com, но правильнее качать последний патч (с 11-ой версии oracle пачти являются полными дистрибутивами) с support.oracle.com 11.2.0.3
Это четвертый из семи диск в дистрибутиве.
А далее внимательно изучить приложенный readme на предмет intallation prerequests и сам installation.
Можно еще последний Opatch и PSU накатить для верности :)
Скачивать его можно с сайта oracle.com, но правильнее качать последний патч (с 11-ой версии oracle пачти являются полными дистрибутивами) с support.oracle.com 11.2.0.3
Это четвертый из семи диск в дистрибутиве.
А далее внимательно изучить приложенный readme на предмет intallation prerequests и сам installation.
Можно еще последний Opatch и PSU накатить для верности :)
>У нас второй день тормозит exadata… причины хрен найдешь.
А чего там искать-то? Зайти в какой-нибудь ейный enterprise manager, вкладка performance->top activity и все как на ладони.
Сколько активных сессий, по каким классам ожиданий и разбивки глубже. Самые тяжелый запросы и т.п…
А чего там искать-то? Зайти в какой-нибудь ейный enterprise manager, вкладка performance->top activity и все как на ладони.
Сколько активных сессий, по каким классам ожиданий и разбивки глубже. Самые тяжелый запросы и т.п…
продукта жизнидеятельности oracle — siebel
От жизнедеятельности Oracle в продукте Siebel — только интеграции с другими оракловыми продуктами.
Сам Siebel к Ораклу никакого отношения не имеет, т.к. родительская контора была поглощена на пике своего развития когда всё уже было разработано.
Единственное что для меня лично отсутствует в PostgreSQL это запуск единственного SQL запроса на отдельных ядрах процессора или параллельное исполнение одного запроса. Oracle естественно мощнее в этом смысле, но опять же, в балансе между функциональностью и стоимостью (да и простотой администрации и настройки) PostgreSQL выигрывает (по крайней мере в моих системах).
Postgres 9.4 меня жестоко разочаровал непонятными тормозами при выборке нескольких десятков тысяч строк из двухсотмиллионной таблицы по BTree индексу. По одному ключу записи выбираются 35 ms, по тысяче ключей — уже полее получаса. Причём с индексом время получается даже польше, чем при seq scan. В explain plan смотрел — ужасно оргомное время поступа именно к индексу. С какого перепугу — неясно.
UFO just landed and posted this here
«так как использование бизнес логики на уровне базы данных в наше время страшный моветон и не приветствуется вовсе»
А чем объективно плоха бизнес-логика на стороне БД?
А чем объективно плоха бизнес-логика на стороне БД?
UFO just landed and posted this here
1. Но мы помним, что язык SQL не так универсален в современном мире? И как минимум небольшой вендор-локин у нас в любом случае.
В частности различные подсказки для оптимизатора, такие вещи как партиционирование и т. д.
В любом случае не получится перенести серьезное приложение без переписывания кода.
2. В каком месте неохотно масштабируется, на реальных вещах если можно?
В частности различные подсказки для оптимизатора, такие вещи как партиционирование и т. д.
В любом случае не получится перенести серьезное приложение без переписывания кода.
2. В каком месте неохотно масштабируется, на реальных вещах если можно?
Ваши слова основываются на реальном опыте? Мне довелось участвовать в разработке одной и той же системы, один вариант которой был реализован на pl/sql, второй — на .net. Так вод логика внутри БД оказалась на порядок быстрее при том, что данных было тоже на порядок больше (на всякий случай уточню: реализовывали биллинговую систему). При этом на привязку к Ораклу было глубоко всем наплевать, ибо переходить ни на что другое даже в мыслях не было, а по масштабированию… база не напрягаясь делала то, на что у дотНета в тестовом прогоне уже не хватало памяти :)
Раскажите роль системы контроля версий, тестов, оценки качества кода и процесса деплоя — вот что будет интересно.
А главное какая была система логирования? Понятно что во время разработки должен быть дебаг режим, а на продуктиве, к примеру, должны быть моментальные оповещения при исключительных ситуациях(например email с данными или смс с угрозой).
А главное какая была система логирования? Понятно что во время разработки должен быть дебаг режим, а на продуктиве, к примеру, должны быть моментальные оповещения при исключительных ситуациях(например email с данными или смс с угрозой).
Да нормально всё с этим. Автономные транзакции для логгирования, для дебага — внутренние настройки софтины и оракловые контексты сессий, DBMS_PIPE, DBMS_ALERT и, наконец, Advanced Queues для организации очередей оповещения. UTL_HTTP, UTL_SMTP и прочее для организации транспорта оповещения. Много что есть интересного и удобного, если доку читать и не пытаться изобретать велосипеды.
Я знаю что все это есть, знаю как сложно с этим работать, а главное знаю что в любом фреймворке любого нормально ЯП Вам даже доку для таких элементарных вещей читать не пришло — это бы просто было и работало.
Покажите мне mail(или что-то типа того) с трейсом ошибки, который Вы сделали или хотя бы используете и я покажу Вам свои, которые просто сами приходят :)
Покажите мне mail(или что-то типа того) с трейсом ошибки, который Вы сделали или хотя бы используете и я покажу Вам свои, которые просто сами приходят :)
Не понял, что не так? Если вы знаете, что в Оракле есть механизмы, то к чему тогда вопросы? То, что нужно написать свою реализацию отправки письма, использующую оракловый пакет, а не воспользоваться готовым фреймворком? Ну да, нужно сделать лишнее ручное движение. Зато скорость работы перекрывает все подобные издержки. Что не так с тестированием? Берете и покрываете тест-кейсами все, что захотите. Какая разница? И да, результаты тестирования можно присылать по СМС-ке, только у нас из-за бесплатности используемого механизма была задержка в 7 мин. Повторюсь еще раз: где во главу угла ставится скорость работы, там большинство фреймворков и шаблонов проектирования идут лесом! Никто не будет оценивать красоту вашей архитектуры и легкость реализации, если система не работает (а медленно работающая считается не работающей!).
Не так, что это всё никто не делает из-за геморойности.
Не так, что продукт будет делать как минимум на порядок дольше(Вы же сами всё пишете).
Не так, что будет больше ошибок(ведь Ваш велосипед только Вы тестируете).
Не так, что изменения сложней вносить.
Не так, что нет IDE для этого.
Не так, что не возможно сделать gracefull restart.
Не так, что Вы будете вынуждены вынести сервер в деметализированную зону для общения с партнерами или всё равно писать вокргу БД какой-то софт.
Не так, что после того как Вы из-за предыдущего пункта напишите какой-то софт, Вам придется владеть 2 раза большим кол-вом технологий, т.е. увеличить технологический долг сразу в 2 раза.
главное конечно — vendor lock-in, но это не в тему.
Не так, что продукт будет делать как минимум на порядок дольше(Вы же сами всё пишете).
Не так, что будет больше ошибок(ведь Ваш велосипед только Вы тестируете).
Не так, что изменения сложней вносить.
Не так, что нет IDE для этого.
Не так, что не возможно сделать gracefull restart.
Не так, что Вы будете вынуждены вынести сервер в деметализированную зону для общения с партнерами или всё равно писать вокргу БД какой-то софт.
Не так, что после того как Вы из-за предыдущего пункта напишите какой-то софт, Вам придется владеть 2 раза большим кол-вом технологий, т.е. увеличить технологический долг сразу в 2 раза.
главное конечно — vendor lock-in, но это не в тему.
Вы часто встречали серьезные системы, в которых заранее не известна база данных? Простая логика говорит, что стараясь подстроится под всех, вы не сможете воспользоваться плюшками ни одной. Поэтому еще на начале проектирования выбирается конкретная СУБД и дальше пляшут от нее. За 12 лет работы я только однажды участвовал в проекте, где по требованиям нужно было сделать поддержку трех различных БД. Во всех остальных случаях база была известна заранее, что позволяло использовать преимущества именно ее.
Теперь про геморойность. А кто сказал, что создание систем — это легко? Да, нужно руками делать вещи, которые в каких-нибудь фреймворках уже готовы. И не факт, что сделанное самостоятельно будет хуже черного ящика, в работоспособность которого веришь со слов индуса. Конечно, это сложнее и ответственности больше. Ну дык и заплатят за систему, обсчитывающую десятки сущностей в секунду против десятков секунд на одну сущность у индусов, гораздо больше :)
PS. Не думайте, что фреймворки и шаблоны — это панацея от всех бед. К сожалению, многие утрачивают здравый смысл в погоне за «правильностью»…
Теперь про геморойность. А кто сказал, что создание систем — это легко? Да, нужно руками делать вещи, которые в каких-нибудь фреймворках уже готовы. И не факт, что сделанное самостоятельно будет хуже черного ящика, в работоспособность которого веришь со слов индуса. Конечно, это сложнее и ответственности больше. Ну дык и заплатят за систему, обсчитывающую десятки сущностей в секунду против десятков секунд на одну сущность у индусов, гораздо больше :)
PS. Не думайте, что фреймворки и шаблоны — это панацея от всех бед. К сожалению, многие утрачивают здравый смысл в погоне за «правильностью»…
Да, очень часто. Точнее я видел тока одну большую систему жестко заточенную на БД.
1. Практически все крупные CRM системы работают на разных базах. Это касается и Oracle Siebel CRM.
2. Практически все BI системы поддерживают разные БД
Все остальное — мелочи и\или говнософт, за редким исключением.
Весь банковский или подобный софт строится вокруг CRM.
Могу предположить, что сильно самописные тока игры, биржи и web гиганты типа google.
А заплатят больше за то, что раньше сделают и будут продавать. Siebel откровенное говно, причем крайне медленное(я бы даже сказал фантастически медленное), но не думаю что бывает софт дороже.
1. Практически все крупные CRM системы работают на разных базах. Это касается и Oracle Siebel CRM.
2. Практически все BI системы поддерживают разные БД
Все остальное — мелочи и\или говнософт, за редким исключением.
Весь банковский или подобный софт строится вокруг CRM.
Могу предположить, что сильно самописные тока игры, биржи и web гиганты типа google.
А заплатят больше за то, что раньше сделают и будут продавать. Siebel откровенное говно, причем крайне медленное(я бы даже сказал фантастически медленное), но не думаю что бывает софт дороже.
Я понял, мы рассматриваем разные типы продуктов. Вы говорите о коробочных вариантах, неких универсальных решениях, готовых «работать» где и с чем угодно, а я имею ввиду штучные системы под конкретных заказчиков. В первом случае интеграторы пытаются натянуть бизнес клиента на имеющийся глобус, во втором — изобретается велосипед под конкретные нужды бизнеса. Так вот в вариантах с «говнософтом», как вы изволили выразиться, тип БД определяется заранее.
О чем и речь, такое ощущение, что господа не имеют опыта работы.
Дело не только в переносимости, когда речь заходит о производительности, разница которого измеряется порядками.
Дело не только в переносимости, когда речь заходит о производительности, разница которого измеряется порядками.
Первым делом нужна надежность и отлаженный цикл разработки.
Только потом можно начинать думать о скорости, тем более что сервера стоят копейки(если на них нет стикера Oracle).
Только потом можно начинать думать о скорости, тем более что сервера стоят копейки(если на них нет стикера Oracle).
Это у вас не хватает опыта серьезных проектов и вы начитавшись умных книжек говорите про то, как важно
соблюдать цикл разработки, и какие вы тут все крутые программисты.
Как у вас красиво деплоится и генерируется код.
В реальной жизни, когда вы столкнетесь с серьезным проектом, когда несколько десятков терабайт текстовой информации нужны здесь и сейчас, все меняется.
И количества программистов, а главное качества, начинает резко не хватать.
А пока да, производительность на втором месте.
соблюдать цикл разработки, и какие вы тут все крутые программисты.
Как у вас красиво деплоится и генерируется код.
В реальной жизни, когда вы столкнетесь с серьезным проектом, когда несколько десятков терабайт текстовой информации нужны здесь и сейчас, все меняется.
И количества программистов, а главное качества, начинает резко не хватать.
А пока да, производительность на втором месте.
Когда от правильности и надежности Вашего кода зависит подсчет бабла, мыслить приходится по другому :)
Вот это классно, когда из-за какой-то мелкой логической ошибки, которую отловил бы unit test в одну строчку, ты
портишь «десятки террабайт», а потом сидишь в даунтайме, пока бэкап накатится :-D
А что не так с десятками террабайт? Проблема купить еще половинку экзадаты?
То, что многие жлобятся на лишних программистов — мягко говоря, проблемы индейцев. (с) EugeneO
Вот это классно, когда из-за какой-то мелкой логической ошибки, которую отловил бы unit test в одну строчку, ты
портишь «десятки террабайт», а потом сидишь в даунтайме, пока бэкап накатится :-D
А что не так с десятками террабайт? Проблема купить еще половинку экзадаты?
То, что многие жлобятся на лишних программистов — мягко говоря, проблемы индейцев. (с) EugeneO
«А что не так с десятками террабайт? Проблема купить еще половинку экзадаты?»
Вы прикалываетесь?
Здесь речь идет в контексте полного ухода от оракла и/или оракл не панацея.
Покупка Экзадаты это конечно не vendor lock-in и прочее, прочее говно с ним связанное.
Вы прикалываетесь?
Здесь речь идет в контексте полного ухода от оракла и/или оракл не панацея.
Покупка Экзадаты это конечно не vendor lock-in и прочее, прочее говно с ним связанное.
Проблема купить Terradata? :)
Ну или для вариант для бедных — один из форков postgres может работать прикидываясь ораклом(для переходного периода) и стоять RAC'ом.
В контексте полного ухода от оракла есть куча прекрасных технологий — hadoop, всякие приватные и не очень обалка и т.д.
Ну или для вариант для бедных — один из форков postgres может работать прикидываясь ораклом(для переходного периода) и стоять RAC'ом.
В контексте полного ухода от оракла есть куча прекрасных технологий — hadoop, всякие приватные и не очень обалка и т.д.
Вы со своими hadoop'ами, знаете куда пойдете, если предложите данное решение банкам например?
А Terradata, это тот же самый vendor lock-in, а так же куча других минусов с ним связанных.
Но суть в том, что все что вы описали и Oracle DB имеют радикально разные предназначения.
А Terradata, это тот же самый vendor lock-in, а так же куча других минусов с ним связанных.
Но суть в том, что все что вы описали и Oracle DB имеют радикально разные предназначения.
Для меня его предназначение — Хранение.
Есть разные способы хранения. У всех есть свои плюсы, минусы и предназначения.
На выбор оракла банками, никак не влияют его возможности.
Но есть редкие руководители банков, которые держат у себя настоящих 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'ом не пользовался. так к слову сказал.
Есть разные способы хранения. У всех есть свои плюсы, минусы и предназначения.
На выбор оракла банками, никак не влияют его возможности.
Но есть редкие руководители банков, которые держат у себя настоящих 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'ом не пользовался. так к слову сказал.
hadoop как замена Oracle? Вы это серьёзно?
Нет, я не про то, что hadoop плох. Просто это немного другое. Ну, всё равно что вилка взамен картошки :)
Нет, я не про то, что hadoop плох. Просто это немного другое. Ну, всё равно что вилка взамен картошки :)
UFO just landed and posted this here
А что вы предлагаете как более надежное?
Вообще, когда разработчик заводит разговоры о производительности в ущерб надежности и при этом приводит в качестве аргументов наезды на чей-то опыт работы — у меня возникают сомнения в том, что этот разработчик когда-либо работал более чем в одном или паре долголетних легаси-энтерпрайзных проектов и интересуется чем-либо за пределами своего маленького мирка.
Наблюдал неоднократно конкретно у ораклистов.
Вот конкретно прямо сейчас наблюдаю охрененные проблемы с масштабируемостью и поддержанием качества в большом старом интернет-проекте сделанном исторически на хранимках.
Наблюдал неоднократно конкретно у ораклистов.
Вот конкретно прямо сейчас наблюдаю охрененные проблемы с масштабируемостью и поддержанием качества в большом старом интернет-проекте сделанном исторически на хранимках.
Почему в ущерб надежности?
Никто не говорил, что PL/SQL менее надежен.
Просто применяются немного иные алгоритмы работы.
Можно например иметь тестовый сервер и прочие решения.
Суть в том, что это не проблемы если их можно решить.
Когда приложение не отвечает на запросы,
тут дисциплиной разработчиков например ничего не добьешься.
И вот это действительно проблема когда не хватает производительности.
Никто не говорил, что PL/SQL менее надежен.
Просто применяются немного иные алгоритмы работы.
Можно например иметь тестовый сервер и прочие решения.
Суть в том, что это не проблемы если их можно решить.
Когда приложение не отвечает на запросы,
тут дисциплиной разработчиков например ничего не добьешься.
И вот это действительно проблема когда не хватает производительности.
На PL/SQL крайне гемморойно писать автоматизированные тесты и субъективно он сам по себе (как и другие диалекты SQL) чересчур толерантен к ошибкам разработчика (там где c# или java упадут на этапе сборки, хранимка радостно уйдет в базу данных, где ее уже могут продолбать тестировщики).
Суть в том, что проблемы можно решать многими способами и решать их ДЕШЕВО выгоднее, чем ДОРОГО. А дешевле всего они решаются тогда, когда исключен человеческий фактор.
Если есть проблема с производительностью выборки или обработки данных в каком-нибудь конкретном месте я первый скажу, что в этом месте нужно написать хранимку. Но не надо писать на них ВСЕ, как это было принято во времена двухзвенных систем, и строить архитектуру приложения вокруг хранимок.
Проблемы с масштабируемостью начинаются тогда, когда начинаются попытки разделить на шарды или федерацию старую базу данных спроектированную под вертикальное масштабирование и с большим количеством выборок с джойнами. А такое сейчас встречается очень часто.
Суть в том, что проблемы можно решать многими способами и решать их ДЕШЕВО выгоднее, чем ДОРОГО. А дешевле всего они решаются тогда, когда исключен человеческий фактор.
Если есть проблема с производительностью выборки или обработки данных в каком-нибудь конкретном месте я первый скажу, что в этом месте нужно написать хранимку. Но не надо писать на них ВСЕ, как это было принято во времена двухзвенных систем, и строить архитектуру приложения вокруг хранимок.
Проблемы с масштабируемостью начинаются тогда, когда начинаются попытки разделить на шарды или федерацию старую базу данных спроектированную под вертикальное масштабирование и с большим количеством выборок с джойнами. А такое сейчас встречается очень часто.
Вот вы сейчас написали, и я улыбнулся. Как же я мог забыть, что наблюдаю сейчас ту же самую картину :)
К слову, мы сейчас этот проект переписываем. И уже СУБД независимо.
К слову, мы сейчас этот проект переписываем. И уже СУБД независимо.
Мне довелось участвовать в разработке одной и той же системы, один вариант которой был реализован на pl/sql, второй — на .net.
Можно по подробнее, это как?
Одна система полностью на pl/sql, другая полностью на .net?
Или перенесли 1 процедуру с pl/sql на .net и показали производительностью pl/sql?
Если последнее, тогда тут я могу вас огорчить, т.к. структура системы будет иначе. А соответственно и способ обращения данным, эффективность кеширования и т.д. будет другой.
Торопился уложиться в 3 минуты редактирования, напортачил :)
Если последнее, тогда тут я могу вас огорчить. Структура системы (при разработке без использования для бизнес-логики в БД)будет иной, а соответственно и способ обращения данным, эффективность кеширования будут иметь совершенно другое значение в скорости работы и реакции приложения.*
Если последнее, тогда тут я могу вас огорчить. Структура системы (при разработке без использования для бизнес-логики в БД)будет иной, а соответственно и способ обращения данным, эффективность кеширования будут иметь совершенно другое значение в скорости работы и реакции приложения.*
Частично.
Некоторые вызовы делаются целиком на стороне БД, и могут вызываться откуда угодно.
Есть еще такая штука, как целостность данных в данном контексте, которая на стороне БД имеет больше шансов на успех.
Всякие банки и тот же билинг критичны к ним.
Некоторые вызовы делаются целиком на стороне БД, и могут вызываться откуда угодно.
Есть еще такая штука, как целостность данных в данном контексте, которая на стороне БД имеет больше шансов на успех.
Всякие банки и тот же билинг критичны к ним.
Разрабатывать большую систему, где целостность данных проверяется на стороне БД, не в идеальных системах крайне трудоёмко. Опять же все утыкается либо в универсальность либо в количесво специалистов. И если целостность контролировать на уровне БД и привлекать дополнительных сепециалистов, нужно так же еще и расширять штат управленцев, которые будут руководить потоком задач от разработчиков на ЯП(языке программирования) к спец PL/SQL и обратно.
+ Нужны дополнительные ресурсы на документирование разделения логики, т.к. код размазан по БД и системе.
К тому же, как правило, целостность на столько сложна, что реализовать её лишь в pl/sql на стороне БД невозможно, т.к. у неё не хватает данных.
+ Нужны дополнительные ресурсы на документирование разделения логики, т.к. код размазан по БД и системе.
К тому же, как правило, целостность на столько сложна, что реализовать её лишь в pl/sql на стороне БД невозможно, т.к. у неё не хватает данных.
>> Можно по подробнее, это как?
Первый вариант — на pl/sql, [почти] двухзвенная архитектура, где клиент знает только названия и параметры хр. процедур, реализующих бизнес-логику, а внутри процедур уже идут выборки, журналирования, проверки прав доступа и т.п.
Второй вариант — на .net, трехзвенная архитектура, когда всю логику реализует сервер приложений, написанный на C#. В этом варианте от БД требуется только insert/update/delete.
Первый вариант — на pl/sql, [почти] двухзвенная архитектура, где клиент знает только названия и параметры хр. процедур, реализующих бизнес-логику, а внутри процедур уже идут выборки, журналирования, проверки прав доступа и т.п.
Второй вариант — на .net, трехзвенная архитектура, когда всю логику реализует сервер приложений, написанный на C#. В этом варианте от БД требуется только insert/update/delete.
поддерживаю. У нас тоже парочка биллинговых систем с логикой в оракле. Там даже ООП удалось использовать в некотором виде — и наследование, в том числе. Работает хорошо. Хотя есть и минусы у этого решения: нельзя разделить по серверам хранение данных и вычисления. но далеко не всегда это, собственно, и нужно.
Тем, что привязывает вас к определенной БД. Языки программирования имеют меньше привязки, даже .NET. Также меньше тулов? как source control или continuous integration. Можно закончить, что вы будете обмениваться DUMP базы данных, а не исходным кодом…
Плюс, с логикой в БД должен разбираться DBA, а с application логикой, программист.
Плюс, с логикой в БД должен разбираться DBA, а с application логикой, программист.
«Плюс, с логикой в БД должен разбираться DBA, а с application логикой, программист.»
Не понял, PL/SQL по вашему имеет отношение к DBA?
Я такого не видел.
Не понял, PL/SQL по вашему имеет отношение к DBA?
Я такого не видел.
и, в некоторых случаях, полностью отвязывает от платформы клиентских приложений или решает многие проблемы с написанием кросс-платформенных клиентов.
И да, с логикой в БД должен разбираться PL/SQL-программист, это не задача DBA.
И да, с логикой в БД должен разбираться PL/SQL-программист, это не задача DBA.
Тем что она, в общем случае, повышает сложность разработки. Т.к. нужно знать что крутится на стороне БД, а что на стороне кода. И что бы это не произошло, нужно четко выделить уровни абстракции заранее. А это, в свою очередь, не очень то и тривиальная задача. Т.к. даже проектирование идет поэтапно.
Плюс, сейчас при проектировании пытаются заложиться на абстрагировании от БД, Так проектировать проще и лучше для бизнеса с точки зрения, предоставления выбора альтернатив заказчику.
К тому же, нужно заложиться на то, что либо ваши специалисты должны уметь писать код на языке программирования и на языке БД, либо всегда иметь отдельных специалистов(и несколько, на случай болезни 1). Что, согласитесь проблематично в 1 случае, и не выгодно во втором.
Плюс, сейчас при проектировании пытаются заложиться на абстрагировании от БД, Так проектировать проще и лучше для бизнеса с точки зрения, предоставления выбора альтернатив заказчику.
К тому же, нужно заложиться на то, что либо ваши специалисты должны уметь писать код на языке программирования и на языке БД, либо всегда иметь отдельных специалистов(и несколько, на случай болезни 1). Что, согласитесь проблематично в 1 случае, и не выгодно во втором.
+1 не видел DBA умеющих программировать, хотя наших даже заставляли делать soap запросы из бд… которые в итоге писали программисты, слава богу эти процедуры пока не используются :-D
Утверждения «не умеет писать код на языке БД» и «не понимает как БД работает» — утверждения практически идентичные — реально одно без другого немыслимо. Писать СУБД должны люди, которые понимают, что такое БД. Иначе настроят чугуниевых велосипедов, которые не ездят.
Писать СУБД должны люди, которые понимают, что такое БД.
Это вы сейчас вообще к чему?
Кто пишет СУБД?
При чём тут написание СУБД?
Утверждения «не умеет писать код на языке БД» и «не понимает как БД работает» — утверждения практически идентичные
Я знаю язык запросов. Я не умею писать хранимые процедуры.
Для меня, как разработчика некого продукта, БД это сервис для хранения данных. Что значит «не понимает как БД работает» — остается очень абстрактной фразой. Уровень понимания работы БД не детерминирован вами.
СУБД — да, неудачная коллизия с устоявшимся термином, хотя подразумевается, разработка сложной системы управляющей базой данных :-)
> Я знаю язык запросов. Я не умею писать хранимые процедуры.
Выходит, вы не знаете язык запросов.
Точно так же как то, что я когда прочитал Страуструпа, и могу матрицы на C++ перемножить, не говорит, что я знаю C++
> Я знаю язык запросов. Я не умею писать хранимые процедуры.
Выходит, вы не знаете язык запросов.
Точно так же как то, что я когда прочитал Страуструпа, и могу матрицы на C++ перемножить, не говорит, что я знаю C++
Выходит, вы не знаете язык запросов.
Я знаю язык запросов для использования БД как систему сохранения и получения данных.
Что бы вам было попонятнее, что я вам говорю, задайтесь вопросом, что такое «понимать как работает БД».
С точки зрения разработчика СУБД, можного говорить, что вы не понимаете как работает БД. С точки зрения прикладного программиста, вы знаете. Определитесь с определением «понимать».
> Я знаю язык запросов. Я не умею писать хранимые процедуры.
Выходит, вы не знаете язык запросов.
Давайте всё-таки определимся со слоями в современных СУБД. Очень-очень грубо и непростительно неточно, потому что быстро и коротко. Ну и поскольку топик про оракл, всё будет в его терминах. Поехали.
Есть строки данных, которые хранятся в блоках, которые объединяются в экстенты, которые принадлежат сегментам. Есть блокировки для защиты строк и защёлки для защиты структур памяти. Давайте вынесем это в нижний, «физический» слой СУБД.
Для управления данными необходим некий интерфейс к ним. В РСУБД этот интерфейс сейчас более-менее стандартизирован и называется Structured Query Language. Движок SQL. Давайте в нашей грубой модели отнесём к его обязанностям описание сущностей в привычных человеку терминах, управление логической целостностью данных и придумыванием, как быстрее всего их вытащить с нижнего слоя.
В 80-ых это был предел желаний и все отлично обходились вариантом «СУБД для хранения и управления данными, а для логики у нас есть куча удобных и прикольных языков». Но аппетиты быстро растут, а идеалы часто меняются, поэтому появилось понимание, что часть логики было бы безумно здорово перенести напрямую в СУБД, чтобы не гонять туда-сюда сырые данные между сервером БД и приложением. Так появился движок PL/SQL. Ничего не напоминает? Рос он рос и дорос до уровня полноценного сервера приложений с великим множеством возможностей и плюшек.
Мораль сей басни: движок SQL и движок PL/SQL — это две совершенно разные вещи. Внешне их постарались причесать под одни и те же стандарты, но внутренне они различаются очень сильно. Множество примеров внутренних (и, обычно, недокументированных) различий можно найти в топиках на sql.ru.
Ну и, наконец, слова SowingSadness`а «знаю язык запросов, но не умею писать хранимые процедуры», говорят лишь о том, что он прекрасно понимает различие между SQL и PL/SQL.
Вы пробывали сделать Continuous Integration для логики в БД?
Если попробуете, до думаю у Вас всё время уйдет на настройку CI и продумывание его архетектуры :-D
А без этого делать что-то серьезное лучше даже не начинать.
Если попробуете, до думаю у Вас всё время уйдет на настройку CI и продумывание его архетектуры :-D
А без этого делать что-то серьезное лучше даже не начинать.
Вы рассматриваете только одну не самую важную деталь вопроса.
Добавьте сюда деплой, версионирование и хранение исходников.
В чем проблема?
Конкретно, в чем проблема версионирования и хранения исходников PL/SQL или какого-нибудь другого хранимого кода?
Конкретно, в чем проблема версионирования и хранения исходников PL/SQL или какого-нибудь другого хранимого кода?
А вы знаете как их нормально хранить — кроме как полный дамп базы со всем хламом?
Как накатывать изменения и откатывать?
Как деплоить их не делая иногда ALTER DATABASE KILL SESSION?
Если вы знаете здесь best practices поделитесь — мне лично очень интересно.
Как накатывать изменения и откатывать?
Как деплоить их не делая иногда ALTER DATABASE KILL SESSION?
Если вы знаете здесь best practices поделитесь — мне лично очень интересно.
> А вы знаете как их нормально хранить — кроме как полный дамп базы со всем хламом?
В данном случае просто нужна дисциплина. Никогда не редактировать и не отлаживать процедуры «по месту», прямо в базе. Строго — скрипт создания процедурного объекта редактируется во внешнем файле (и сохраняется в системе управления версиями), только после этого он исполняется в СУБД.
В данном случае просто нужна дисциплина. Никогда не редактировать и не отлаживать процедуры «по месту», прямо в базе. Строго — скрипт создания процедурного объекта редактируется во внешнем файле (и сохраняется в системе управления версиями), только после этого он исполняется в СУБД.
Мы говорим про хранимую логику — зачем полный дамп? Если речь идет не об изменении структур данных и самих данных, которые безразлично от местонахождения логики придется менять/откатывать, то местонахождение логики в базе практически ничем не отличается от промежуточных слоев. pl/sql — это тоже клиент.
Ну попробуйте хотя бы описать как бы Вы всё это реализовали.
Вот есть вариант geekswithblogs.net/SQLDev/archive/2012/04/24/database-continuous-integration-step-by-step.aspx
На мой взгляд он очень полный и жутко геморойный, по сравнению любым нормальным ЯП.
Вот есть вариант geekswithblogs.net/SQLDev/archive/2012/04/24/database-continuous-integration-step-by-step.aspx
На мой взгляд он очень полный и жутко геморойный, по сравнению любым нормальным ЯП.
Это всё и есть CI
CI — это только автоматизированная сборка. Все вместе — continious delivery
Paul M. Duvall, Steve Matyas, Andrew Glover с Вами не согласны :)
www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380
Хотя я уже встречал такое понятие. CI мне ближе, потому что все сервера CI обязательно указывают в списке фич — деплой.
т.е. для меня CI
— репозиторий
— тесты
— оценка качества кода
— сборка
— выкатка
— различные «тормозисторы» сборки и выкатки
www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380
Хотя я уже встречал такое понятие. CI мне ближе, потому что все сервера CI обязательно указывают в списке фич — деплой.
т.е. для меня CI
— репозиторий
— тесты
— оценка качества кода
— сборка
— выкатка
— различные «тормозисторы» сборки и выкатки
Я спросил про то, с чего надо начать при разработке. Это не самая главная и не самая важная — это первая деталь.
Почитайте про Edition-Based Redefinition, почитайте старые проверенные простые методы. Все легко и просто. Вообще постарайтесь меньше делать громких заявлений, не имея знаний и опыта, т.к. со стороны это выглядит крайне ужасно.
«А чем объективно плоха бизнес-логика на стороне БД?»
Попробую ответить, чем, по моему мнению, плоха бизнес-логика, реализованная на стороне БД. Во-первых, увеличивается нагрузка на сервер БД. СУБД занимается теперь не только своими непосредственными обязанностями, но вообще чем угодно. Непонятно, кто сколько ресурсов потребляет, как он это делает, какая часть чем занимается. Как это паралеллить? Как это масштабировать в дальнейшем? Вертикально? Горизонтально?
Во вторых, строго говоря, в функции СУБД не входит выполнение каких-либо команд, не относящихся к извлечению данных. А тут все наоборот — в одной СУБД наворочено черте что — 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 — в принципе, не так и страшно, если вендор хороший.
Реализация бизнес-логики на уровне СУБД страшный моветон сегодня именно потому, что к сегодняшнему моменту мы имеем кучу систем, которые непонятно, как дальше поддерживать и как дальше масштабировать. Да, они выполняют свои функции в каких-то пределах, а что делать дальше? Не проще ли проектировать такие системы, которые можно поддерживать за разумные деньги и время? Или важнее выйти на рынок раньше всех, а потом думать, как же допилировать её дальше?
Попробую ответить, чем, по моему мнению, плоха бизнес-логика, реализованная на стороне БД. Во-первых, увеличивается нагрузка на сервер БД. СУБД занимается теперь не только своими непосредственными обязанностями, но вообще чем угодно. Непонятно, кто сколько ресурсов потребляет, как он это делает, какая часть чем занимается. Как это паралеллить? Как это масштабировать в дальнейшем? Вертикально? Горизонтально?
Во вторых, строго говоря, в функции СУБД не входит выполнение каких-либо команд, не относящихся к извлечению данных. А тут все наоборот — в одной СУБД наворочено черте что — 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 — в принципе, не так и страшно, если вендор хороший.
Реализация бизнес-логики на уровне СУБД страшный моветон сегодня именно потому, что к сегодняшнему моменту мы имеем кучу систем, которые непонятно, как дальше поддерживать и как дальше масштабировать. Да, они выполняют свои функции в каких-то пределах, а что делать дальше? Не проще ли проектировать такие системы, которые можно поддерживать за разумные деньги и время? Или важнее выйти на рынок раньше всех, а потом думать, как же допилировать её дальше?
>Пользуетесь DBMS_JOB? В 11g это теперь включено в DBMS_SCHEDULER — надо переделывать.
Это не так, ничего переделывать не нужно — все что сделано на dbms_job будет работать в 11g без проблем :)
В целом с Вами согласен. Хотя, мне кажется, что простота поддержка больше зависит от качества менеджмента проекта, изначально — в первую очередь правильно разработанной реляционной модели БД и грамотно причесанных бизнес-процессов, качества документирования и т.п., а способы реализации в БД или нет могут влиять больше на то, где у нас будут узкие места в плане производительности, т.е надо выбирать исходя, что мы создаем — биллинг мобильного оператора (склоняюсь к БД) или, например, facebook (тут как раз надо все выносить).
Как говорят — если автоматизировать бардак, то получится автоматизированный бардак и ничего более :)
Это не так, ничего переделывать не нужно — все что сделано на dbms_job будет работать в 11g без проблем :)
В целом с Вами согласен. Хотя, мне кажется, что простота поддержка больше зависит от качества менеджмента проекта, изначально — в первую очередь правильно разработанной реляционной модели БД и грамотно причесанных бизнес-процессов, качества документирования и т.п., а способы реализации в БД или нет могут влиять больше на то, где у нас будут узкие места в плане производительности, т.е надо выбирать исходя, что мы создаем — биллинг мобильного оператора (склоняюсь к БД) или, например, facebook (тут как раз надо все выносить).
Как говорят — если автоматизировать бардак, то получится автоматизированный бардак и ничего более :)
Спасибо, очень классно написано! Повеселили от души! :)
Но, очень странное суждение про применение ExaData для DWH/OLTP
Я как раз считал, что ExaData идеальна для DWH так как:
1. умеет все классно параллелить
2. пропихивает условия из where на уровень «дискового массива», что в результате рвет на грелки все остальные решения, где надо через оптику или т.п прокачать терабайты данных между сервером и массивом.
А для OLTP, все что содержит в себе RAC при условии не заточенности приложений — один сплошной гемор — меж-инстансные блокировки и т.п. Это ужас-ужас…
Но, очень странное суждение про применение ExaData для DWH/OLTP
Я как раз считал, что ExaData идеальна для DWH так как:
1. умеет все классно параллелить
2. пропихивает условия из where на уровень «дискового массива», что в результате рвет на грелки все остальные решения, где надо через оптику или т.п прокачать терабайты данных между сервером и массивом.
А для OLTP, все что содержит в себе RAC при условии не заточенности приложений — один сплошной гемор — меж-инстансные блокировки и т.п. Это ужас-ужас…
А у нас на ExaData OLTP :-D
А всё почему? Потому что продажники Oracle — боги и по совместительству главный актив компании. :)
А всё почему? Потому что продажники Oracle — боги и по совместительству главный актив компании. :)
Exadata хороша для DWH, скажем так, относительно небольших размеров. У нее есть определенные сложности с масштабированием, хотя они попытались решить это превентивно с помощью InfiniBand.
Есть неплохой документ от Teradata, описывающий основные недостатки Exadata. Ссылка
По мне, основной недостаток — это не MPP система, соответственно, масштабируется плохо. А так, она вполне подходит для среднего класса DWH, если не обращать внимания на её эффективность за такие деньги.
Есть неплохой документ от Teradata, описывающий основные недостатки Exadata. Ссылка
По мне, основной недостаток — это не MPP система, соответственно, масштабируется плохо. А так, она вполне подходит для среднего класса DWH, если не обращать внимания на её эффективность за такие деньги.
Ну, статья от конкурентов вряд ли может претендовать на полную объективность :)
С другой стороны меня только радует, что у oracle по еще есть серьезные конкуренты и хотелось бы, чтобы их было больше. Так как по мне качетсво самой oracle rdbms в плане надежности с тех пор, как я им занимаюсь (1998) изрядно падает.
БД уже напоминает анекдот про самолет с бассейном и прочим, который теперь еще и попытается взлететь :)
С другой стороны меня только радует, что у oracle по еще есть серьезные конкуренты и хотелось бы, чтобы их было больше. Так как по мне качетсво самой oracle rdbms в плане надежности с тех пор, как я им занимаюсь (1998) изрядно падает.
БД уже напоминает анекдот про самолет с бассейном и прочим, который теперь еще и попытается взлететь :)
Видел DWH на Oracle (даже не Exadata) и на Teradata. Различие между ними только одно — Oracle работает.
Справедливости ради, GreenPlum и MS Parallel DWH — тоже работают, и по соотношению стоимость/эффективность вполне возможно, не хуже. Но Терадата — это аццкий ад :(
Справедливости ради, GreenPlum и MS Parallel DWH — тоже работают, и по соотношению стоимость/эффективность вполне возможно, не хуже. Но Терадата — это аццкий ад :(
Слог шикарный…
Если вкратце, то полный цикла разработки — это все круги Ада.
Промазал — это ответ на этот комментарий
За что же вы так с лисой? :)
Спасибо за отличную статью. Как жрец ДБА, посмеялся от души. А Оракл… Уже скоро будет 12c, а долговременное хранение ASH data нет, только 10% в авр. Я готов сотни гигабайт под ASH снэпы отдавать, но хоть убейся.
А нафига?
Потому что у нас на проде ASH смывается примерно за час-полтора. Не всегда этого времени хватает, чтобы до конца решить проблему производительности. Иногда, если жалоба пришла чуть позже, из AWR просто невозможно уже вытащить нужные данные. Звучит, конечно, довольно наивно, но я не раз сталкивался с ситуациями, когда жалел об отсутствии выгрузки эша на диск 1:1, а не 1:10.
Хм… а если увеличить частоту снятия snapshots? У меня стоит 15 минут, вместо дефолтных 30-ти.
Посмотрел ash на своем проде — хранится последние 70 минут :(
Посмотрел ash на своем проде — хранится последние 70 минут :(
В 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, по-моему, не проблема.
Причём, в данный момент я борюсь с багом (которому нет фикса, привет, Оракл), из-за которого WRH$_ACTIVE_SESSION_HISTORY не сплитается и не пурджится. С февраля 2012 она выросла лишь до 14ГБ примерно. Это та таблица, к которой обращаешься через dba_hist_active_sess_history. Соответственно, если бы можно было хранить эш 1:1, она была бы 140ГБ. Почти за год! На нагруженном продакшне под EBS+SOA+OBIEE+whatnot. Т.е. хранить неделю ASH 1:1, по-моему, не проблема.
Если Вы brave enough и готовы оказаться буратиной для oracle support и, если есть тестовая системка, на которой можно проиграть хорошую нагрузку, то можете попробовать поменять параметр
_ash_disk_filter_ratio с дефолтного 10 на 1-ку :)
Испугали Вы меня этим багом, полез смотреть — все ок, партиции сплитятся каждые четыре дня, каждая объемом порядка 2Гб, хранятся за последние 3 месяца.
У меня 11.2.0.3.2 HP-UX IA64 + еще с десяток one-offs.
_ash_disk_filter_ratio с дефолтного 10 на 1-ку :)
Испугали Вы меня этим багом, полез смотреть — все ок, партиции сплитятся каждые четыре дня, каждая объемом порядка 2Гб, хранятся за последние 3 месяца.
У меня 11.2.0.3.2 HP-UX IA64 + еще с десяток one-offs.
Спасибо, кстати, надо бы попробовать на тестовом трупике дома :)
11.2.0.2.5 Oracle Linux 5 + uek. Заметили баг, когда аудит базы проводили. Ещё и WRI$_OPTSTAT_HISTHEAD_HISTORY не пурджится. А мануал пурдж бежит по 48 часов на неделю статистики :(
Причём, что самое интересное, сплиттинг через
11.2.0.2.5 Oracle Linux 5 + uek. Заметили баг, когда аудит базы проводили. Ещё и WRI$_OPTSTAT_HISTHEAD_HISTORY не пурджится. А мануал пурдж бежит по 48 часов на неделю статистики :(
Причём, что самое интересное, сплиттинг через
alter session set "_swrf_test_action" = 72; срабатывает. Даже пурдж срабатывает (я руками сделал сплит, через неделю ещё сплит, вот на днях ушла вторая партиция. Оригинальная огромная партиция так и осталась висеть). Саппорт разводит руками. Есть, вроде бы, патч, но он требует перевода базы в апгрейд, чего бы не хотелось, я не продавлю наверх. Наверное, в ежевоскресный мэйнтенанс добавится ещё один шаг. Эх, ладно, пожаловался на жизнь :)Кстати, в дополнение к тому, что верно сказал zhekappp, еще могу посоветовать скрипты Танела Подера(snapper, latchprofx и тд). А вообще(не знаю, конечно, какие проблемы решаете вы) серьезные проблемы производительности обычно либо замечаются и решаются сразу, либо легко видны в awr(или еще где-нибудь, в зависимости от характера проблемы), либо легко повторяются. У нас хранение awr две недели — если за этот срок не сообщили о проблеме, значит это и не проблема…
Sign up to leave a comment.
Oracle, как религия