Вячеслав ЛюбомудровНу, разнообразный опыт он совсем не тот

Он систематизируемый.
За 20 лет опыта для меня нет священных коров и любимых детищ и своих и чужих.
у всех систем есть свои достоинства и недостатки.
я не собираюсь быть адвокатом ни оракла ни информикаса ни постргеса ни С C++ С#
ни джавы.
Они для меня инструменты как микроскоп , молоток, шуруповерт ....

зы как я мог такое забыть, есть это unix операционные системы, не важно
какие хоть ско хоть солярис хоть аикс хоть линукс, лишь бы не винда :)

NETClientд0kХ Инфа для общего развития и более глубокого погружения в тему Друг, на твою ссылку я уже сегодня натыкался, когда пытался найти для тебя разницу между iso-шным read commited и его ораколовой реализации.

В твоей ссылке про read commited говорится только про чтение зафиксированных данных (даже упоминается Oracle), но нигде не говорится о согласованности чтения. Может быть весь этот сыр-бор от твоего не понимания этой разницы?

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

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

NETClientЛадно. Пятница. Я пошел домой. По пути надо сделать рассматриваемую нами с тобой задачу - перевести деньги с одного счета на другой. И мне остается только гадать, что же там будет - версионник или блокировочник.

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

dbms_photoshopд0kХВ работе мне часто приходилось сравнивать таблицы
на разных серверах я ганял left outer join через дблинк.
Информикс всегда работал в десятки раз быстрее.Видно глубокое понимание работы оптимизаторов.
Если у Оракла есть определенные пробелы при построении планов распределенных запросов, то делать вывод про оптимизатор в целом можно только при полном отсутствии логики.

Самая сложная часть в стоимостном оптимизаторе - query transformation, имхо.
Это то, где наибольшее раздолье для системы, чтоб превратить говнокод в нормальный запрос.
И это то, где у Оракла огромный разрыв от конкурентов (я сравниваю с MSSQL и движками для Big Data, которые знаю достаточно неплохо).

Так что, когда речь идет про запрос вида select * from t1 left join t2 on ... здесь трансфорамции вообще не нужны и выводу про "крутость" оптимайзеры слышать весьма смешно.

Учитывая что с 12.2 когда Oracle начал поддерживать sharding, полагаю что здесь все ключевым образом изменилось.
Только изменения CBO скорее всего весьма незначительны.

Вы действительно хотите про это гребаный оптимизатор поговорить ?
:)
возможно иое мнение субъективно , потому что
я чесно заипался пинать с говнокодеров с одной стороны, а оптимизатор с другой .
И не только я, а и вся команда админов .

тут более предметно
Example 15-1 Parent Cursors

Тянеш оптимизатор в одну сторону одни ожидания на шаред пуле , тянешь в другую другие ,
пытаешься донести информацию об оптимизаторе до говнокодеров , как горохом об стенку.

dbms_photoshopд0kХпро это гребаный оптимизатор поговорить ?Нет, не хочу.
Это уже дичайший оффтоп даже в рамках офтопа.

Вторую твою ссылку "Improving Real-World Performance Through Cursor Sharing" можно перевести как "Улучшение Говно-Дизайна путем костылей".
И даже там четко сказано большими буквами отдельным параграфом



В второй ссылке гораздо интереснее случай описан



авторIn this example, the first two statements are syntactically different (the letter “c” is lowercase in the first statement and uppercase in the second statement), but semantically identical. Because of the syntactic difference, these statements have different parent cursors. The third statement is syntactically identical to the first statement (lowercase “c”), but semantically different because it refers to a customers table in a different schema . Because of the syntactic identity, the third statement can share a parent cursor with the first statement.


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


dbms_photoshopЯ понимаю твою боль когда среди разрабов нет адекватных.
Как я уже упоминал, при использовании того же хадупа твоя жизнь вообще превратится в ад.
Там все станет колом еще раньше и исправить будет еще сложнее.
Я в курсе относительно проблем в консерватории не_только_sql-ей.

И вобще хорошо там где нас нет :)

Еще очень много интересносетей происходит
когда размерности полей массово не совпадают с размерностями
пременных в pl/sql коде,
после некоторого значения наступает лавинообразный эффект
оптимизатор сносит крышу шаред пулу.

RA\/ENд0kХразница только в том, что проблемы проектах на блокировчниках вылазят на этапе тестирования и их видно сразу.
а на версионниках в процессе эксплуатации с ростом конкурентной нагрузки, но кого это интересует

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

Характерный пример бонусов блокировочника - долгим запросом на реплике БД тормознули собственно репликацию, а она тормознула или вообще всю АБС (или значительную часть, связанную с главной книгой - не помню точно) банка из первой десятки.
Ну а сам как-то не уследил, что коннект на виртуалке не к ораклу, а к какому-то г**ну, и после сбоя сети не полез окно с запросом закрывать - тормознул какую-то систему в другом банке (из той же десятки). Не очень ругали, саппорт там к подобному привычный. ХЗ что это за база была, уже не помню, простой select вызвал блокировку.
Вы наверное не читали весь топик.
Я выше говорил , что блокировчники жестоки, и куяк куяк и в продакшин
не прощают.
А оракл слишком мягок, идет на поводу и потакает говнокодерам.
Я не пытаюсь быть адвокатом ни для тех ни для других.

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

Мне пока пофик , у меня базы в частном облаке, и я даже
имею маленькое право голоса, какие базы будут жить в этом частном облаке.
и в какую сторону будет развиваться ИТ в компании.
У меня в этом вопросе дилема, куда ехать с 12.1 оракла с его кучей багов,
обратно на 11 , или ждать у моря погоды с 12.2, сколько ждать ?

Моя практика показывает , если в систему установлен патч
или следующая версия ,
и ее по каким то причинам приходится откатывать обратно,
то эта система в целом умрет и будет выведена из безнес процесов через 3-5-7 лет.
Сейчас наступило время принимать решение по ораклу 12.1.
в нем есть куча не решенных вопросов.
Либо вперед на 12.2, либо откат на 11 и поиск алтернатив, вплодь до набора
собственной команды сишников по допиливаю постгриса.
Мне это решение нравится больше всего.

RA\/ENд0kХВы наверное не читали весь топик.
Я выше говорил , что блокировчники жестоки, и куяк куяк и в продакшин
не прощают.
А оракл слишком мягок, идет на поводу и потакает говнокодерам.
Я не пытаюсь быть адвокатом ни для тех ни для других.

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

Мне пока пофик , у меня базы в частном облаке, и я даже
имею маленькое право голоса, какие базы будут жить в этом частном облаке.
и в какую сторону будет развиваться ИТ в компании.
У меня в этом вопросе дилема, куда ехать с 12.1 оракла с его кучей багов,
обратно на 11 , или ждать у моря погоды с 12.2, сколько ждать ?
1. Не просто "жестоки", а вносят неоправданные ограничения и удорожают производство. Этак можно начать ругать говноджавистов и вспоминать С, где "куяк-куяк-в продакшен" тоже не простительно.


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

RA\/EN2. Чтобы не было дилеммы, куда деваться с 12.1, надо было учитывать опыт предыдущих релизов, которые до приличного состояния доползли к 9.2.0.6, 10.2.0.4, 11.2.0.(не помню). Ответ - после первой точки в номере версии. Ну а раз повел продакшен в сырую модную версию - не стоит жаловаться.


Этот опыт не всегда работает, например в случае использования utl_http, 11 версия
не поддерживает и не планирует поддерживать то, что требуют безопасники.
Либо 12, либо рефакторинг. в 12 версии повылазили другие неприятности,
которые должны исправиться в 12.2, но он доступен только в публичном облаке.
Отвтатительно то что изза оракла нельзя ничего спланировать.

RA\/ENд0kХЕсть такая штука, называется закон дырявых абстракций,
когда разработчики не хотят осознавать его наличие, далеко в продуктиве
становится мучительно больно эксплуататорам. Подозрительно знакомый мотив любимой разработчиками и архитекторами песни "для разработки данного функционала на правильном уровне качества надо 1000 MD, а негодяи-продавцы, как обычно, закоммитились на 500". Не очень люблю Спольски за попсу и передергивания.

д0kХЭтот опыт не всегда работает, например в случае использования utl_http, 11 версия
не поддерживает и не планирует поддерживать то, что требуют безопасники.
Либо 12, либо рефакторинг. в 12 версии повылазили другие неприятности,
которые должны исправиться в 12.2, но он доступен только в публичном облаке.
Отвтатительно то что изза оракла нельзя ничего спланировать.
HTTP? В базе? Хм... Я, в общем, не против, но разве любою проблему безопасности в этом протоколе нельзя решить с помощью nginx, туннелем, ETL-средством или достаточно простым самопальной прокси? Дешевле выйдет, чем на постгре переезжать.

А вы не заметили у себя взаимоисключающих параграфов
между 1000 vs 500 и
"nginx, туннелем, ETL-средством или достаточно простым простым самопальной прокси?"
:)
За 500 ,
проще использовать оракловую дырявую абстракцию из коробки,
чем делать решение правильными инструментами.

RA\/ENКасаемо темы 12.2 и публичного облака - я слабо представляю, как туда будут мигрировать банки, например. Или завязанные на активное общение БД с оборудованием заказчика - если middle-tier еще можно затащить в то же облако, что и базу, то ККМ и прочее оборудование, которому нужен достаточно быстрый доступ к БД, в публичное облако не затащить, разве что в приватное. Но почему все про облака говорят - не понимаю, как приватное облако, админящееся силами самого оракла, будет соответствовать PCI DSS. Пожужжат-пожужжат, потому словят падение продаж, уволят несколько менеджеров и будет очередная версия 12.2.0.Х безо всяких облачно-маркетинговых прибамбасов. Вот и админы понадобятся, особенно первое время.
Все похоже на то, что ядро 12.2 на определенном железе уже оттестировали, а на остальном как-то глюковато. Поэтому запустили пока только в облачной версии "типа так и было задумано". Ну или предполагаемое количество глюков настолько велико и технология их локализации по трейсам слишком медленная.

Мне в принципе всеравно , для меня оракл не является "священной коровой",
Чем сильнее оракл будет выкручивать руки, в попытках сманить в свое облако, тем быстрее
ему найдется альтернатива.

RA\/ENд0kХА вы не заметили у себя взаимоисключающих параграфов
между 1000 vs 500 и
"nginx, туннелем, ETL-средством или достаточно простым простым самопальной прокси?"
:)
За 500 ,
проще использовать оракловую дырявую абстракцию из коробки,
чем делать решение правильными инструментами.
Вообще настроить nginx или туннель выйдет дешевле колхоза на utl_http, мне кажется, просто надо выйти за рамки оракла. И utl_http -это не "дырявая абстракция", а костыль с древних времен, такая плюшка для рукожопов, не умеющих в Java и сервисы. Использовать его в продуктиве для критичных процессов - крайне глупо. Я подобные костыли использовал по причине жадности КАМа - лучше сделаем велосипед за свой бюджет, чем поделимся им с соседним подразделением. Но если делаешь через жопу - оракл виноват лишь в том, что предоставил тебе такую возможность, и только.


Мое дело маленькое , я эксплуататор, если программисты и софтверные архитекторы
посчтали, что сделать в оракле одним юнитом за 500 будет лучше
чем умеет nginx жаба или пых за 1000 тремя юнитами,
пусть будет так.
Сейчас они перписывают по 11 версию, потому что мы забраковали 12-ю.

RA\/ENд0kХМне в принципе всеравно , для меня оракл не является "священной коровой",
Чем сильнее оракл будет выкручивать руки, в попытках сманить в свое облако, тем быстрее
ему найдется альтернатива. В определенных нишах - конечно, причем независимо от попытки уехать в облако. Но как универсальное средство он еще долго будет в правом верхнем углу гартнеровского квадрата. Облако даже может дать рост для мелких клиентов, не связанных строгими правилами защиты информации.
Облако это круто во всех нишах.
для больших систем оно должно быть частное.

Alexander Ryndinд0kХОблако это круто во всех нишах.
для больших систем оно должно быть частное.Oracle и это делает.
Если нужна Exadata или BigData в частном облаке, то это Exadata или Big Data Cloud Machine .
Если нужна обычная база Oracle в частном облаке плюс другие сервисы (IaaS, MWaas, etc), то обычная Oracle Cloud Machine .

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

Лично мне нужна точная дата когда можно будет
обновить БД с версии 12.1 до версии 12.2 в частном цоде.
Все!